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

"Из-за ошибки уязвимость в libnv была устранена во FreeBSD не полностью"	+/–
Сообщение от opennews (??), 30-Сен-24, 09:01
В выпущенном в начале сентября исправлении уязвимости в библиотеке libnv выявлена логическая ошибка, из-за которой  уязвимость не устранялась должным образом и система оставалась подвержена атаке. Библиотека libnv развивается проектом FreeBSD и используется в ядре и в приложениях из базовой системы для обработки списков в формате ключ/значение и для огранизации передачи данных при межпроцессном взаимодействии. Библиотека основана на алгоритме nvlist, применяемом в проекте OpenZFS, но во FreeBSD создана собственная реализация, поэтому уязвимость не затрагивает OpenZFS... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=61956
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	–17 +/–
Сообщение от Аноним (1), 30-Сен-24, 09:01
>было исправлено ещё 345 Лихо. Надо полагать, что большинство связаны с сишкой. Очевидно, язык не справляется со своими задачами.
Ответить | Правка | Наверх | Cообщить модератору

	3. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+6 +/–
	Сообщение от Аноним (3), 30-Сен-24, 09:12
	Вот это приплёл...
	Ответить | Правка | Наверх | Cообщить модератору

	81. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+2 +/–
	Сообщение от Кулёк (?), 30-Сен-24, 18:22
	А, что, это не очевидно? С чем же ещё? Читайте что написано, опять и опять: "Уязвимости вызваны обращением к уже освобождённой области памяти". В Rust таких проблем нет. И не надо опять вот тут что там всё unsafe посыпано. Иногда просто нет возможности гарантировать безопасность, но есть очень большая разница когда ты сознательно делаешь opt-in и ограничиваешь область такого кода и тем когда у тебя весь код потенциально одна большая проблема с безопасностью как в случае с С/С++. Всё уже выяснили, Google вон делал исследование по поводу безопасности, там всё ясно и понятно: хочешь меньше проблем - не пиши код на Си, только фикси его, всё новое - только на Rust. Си не уходит исключительно потому что много людей которые его уже знают и много кода написано, но это всё конечно же изменится со временем. А потом и Rust заменится чем-нибудь более продвинутым. Это называется "прогресс". 20 лет назад такие же сидели и ныли что нафиг нам питон вместо фортрана, ну и где он?
	Ответить | Правка | Наверх | Cообщить модератору

	101. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+/–
	Сообщение от Аноним (101), 30-Сен-24, 21:00
	1. Rust - не прогресс. 2. Python - не прогресс. 3. Гугль думает только о собственном кармане. 4. Кому нужна повышенная надёжность - пожалуйста, используйте Redox или Ironclad (формально верифицированное ядро на Ada).
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+/–
	Сообщение от Минона (ok), 30-Сен-24, 21:47
	А редокс тоже формально верифицирована?
	Ответить | Правка | Наверх | Cообщить модератору

	111. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+/–
	Сообщение от Аноним (111), 30-Сен-24, 22:50
	Нет. Инструменты для Rust ещё только развиваются, типа Verus
	Ответить | Правка | Наверх | Cообщить модератору

	108. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	–2 +/–
	Сообщение от Ivan_83 (ok), 30-Сен-24, 22:45
	Пересмотрите бойцовский клуб на досуге, только когда они в самолёте будут беседовать про авто аварии замените это на ошибки в коде и вы всё поймёте в этой жизни. Только у фанатиков есть цель победить все ошибки и уязвимости, обычным людям надо чтобы нечто работало с минимальными затратами. Ошибки, уязвимости - вообще не проблема, пока не случается как у краудстрайка фигня которая всё ломает.
	Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

	127. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+/–
	Сообщение от Аноним (-), 01-Окт-24, 00:24
	А откуда ты узнаешь что оно вылезет для одного пользователя или для почти всех дистрибутивов? Небось авторы CUPS тоже думали "ну написал я плохой код, ну что может случиться". А по поводу автоаварий - вон тойотовцы уже написали код абыкак - убили больше сотни человек.
	Ответить | Правка | Наверх | Cообщить модератору

	136. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	–1 +/–
	Сообщение от Ivan_83 (ok), 01-Окт-24, 02:25
	Ну убили, с кем не бывает. Теперь бери формулу из БК и считай сколько надо трупов чтобы отозвать партию определённого размера :) Вы хотите тотальной безопасности - так не бывает. Проще застраховатся чем бесконечно вкладыватся в безопасность.
	Ответить | Правка | Наверх | Cообщить модератору

	138. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+/–
	Сообщение от Аноним (-), 01-Окт-24, 04:35
	> Ну убили, с кем не бывает. > Теперь бери формулу из БК и считай сколько надо трупов чтобы отозвать > партию определённого размера :) > Вы хотите тотальной безопасности - так не бывает. > Проще застраховатся чем бесконечно вкладыватся в безопасность. ЧСХ хруст в конфигурации как тойота - не поможет вообще совсем никак. Он такое переполнение стека в системе без MMU не увидит от слова никак. А если лэйаут памяти будет делать еще и ламер, что в случае хруста куда вероятнее - там потом тоже будет знатный факапище. От такого только комплекс мероприятий помогает. Но тойотчики ухитирлись забить на пяток правил мисры, облажаться с оценкой использования стека и сделать вообще очень много странной фигни. От которой помогает таки только хорошая взбучка руководству, чтобы не хотелось нарушать критичные правила индустрии в угоду датам релиза, радости руководил, удачным отчетам и проч.
	Ответить | Правка | Наверх | Cообщить модератору

	146. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+1 +/–
	Сообщение от Аноним (146), 01-Окт-24, 11:34
	> Ну убили, с кем не бывает. Ну так когда тебя какой-то такой же бракодел угробит, надо будет в эпитафии написать "Иван был не против, экономьте на коде и дальше" > Теперь бери формулу из БК и считай сколько надо трупов чтобы отозвать партию определённого размера :) Хватило 89 человек для того чтобы бракоделы заплатили 16 миллиардов долларов. Миллиардов, не миллионов. > Вы хотите тотальной безопасности - так не бывает. Давай выключим светофоры - они ж ограничивают водителей, а тотальной безопасности не дает. И ПУЭ выкинем - оно не защищает на 100%, ну подумаешь кого-то єл-вом бахенет. А проверять лекарства годами... проще на всяких Иванах проверить. Вообще странно читать от такого немолодого пользователя такой лютый бред. > Проще застраховатся чем бесконечно вкладыватся в безопасность. Не бесконечно. А "достаточно". Достаточность меняется со временем, тк технологии развиваются. Раньше "молочка из-под буренки попил и не помер - уже отлично", а сейчас "пастеризация, хранение в холодильнике".
	Ответить | Правка | К родителю #136 | Наверх | Cообщить модератору

	163. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+/–
	Сообщение от Ivan_83 (ok), 01-Окт-24, 22:07
	Забавно как вы со своей шизой топите за безопасный код и даже близко не подозреваете о всех других возможностях потерять здоровье и жизнь. Долбанутый японский регулятор может и 100500 ярдов назначать штраф, мистер Тойода просто встанет однажды и скажет: "катитесь к херам", и закроет компанию, ликвидирует так чтобы оно не возродилось, и пойдёт пить сокэ с гейшами - ему то хватит до конца жизни. И где потом будет япония с регуляторами? Что регуляторам скажут все потерявшие работу?) Светофоры это замена регулировщика, и называются они traffic lights и оба названия подразумевают что они про управление потоками ради собственно оптимизации этих потоков а не ради безопасности. Безопасность там производный продукт. Когда это всё появилось к смертям относились сильно проще. Раст не та технология. Языков с безопасной памятью - вагон и тележка, и возрастом они все сильно старше раста. Все кому было надо - уже давно в безопасности, либо используя ЯП либо практики типа мисра. Но теперь появились растисты и мир оказался в опасносте.
	Ответить | Правка | Наверх | Cообщить модератору

	172. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+/–
	Сообщение от Аноним (-), 02-Окт-24, 12:07
	> Забавно как вы со своей шизой топите за безопасный код и даже близко не подозреваете о всех других возможностях потерять здоровье и жизнь. Чувак, сейчас в мире куча стран перебрасывается ракетами, бомбами, а на горизонте маячит перспектива мировой (возможно ядерной). Но это не значит, что надо писать овнокод и делать свою работу тяп-ляп. > Долбанутый японский регулятор может и 100500 ярдов назначать штраф, Регулятор был американский) > мистер Тойода просто встанет однажды и скажет: "катитесь к херам", и закроет компанию, ликвидирует так чтобы оно не возродилось, и пойдёт пить сокэ с гейшами - ему то хватит до конца жизни. А должен был сделать харакири, тк в японской культуре фигово делать работу это позор. > И где потом будет япония с регуляторами? Что регуляторам скажут все потерявшие работу?) Думаешь не найдется того, кто захочет занять его нишу? Свято место пусто не бывает. Придет на его место какой-то Яцизаши-сан, который решит "овнокодить не будем" и начнет выпускать что-то свое. Ты наверное из тех, кто не против когда асфальт прямо в лужу кладут или выпускают уже ржавое ведро прямо с завода. > Светофоры это замена регулировщика, и называются они traffic lights и оба названия  подразумевают что они про управление потоками ради собственно оптимизации этих потоков, а не ради безопасности. Безопасность там производный продукт. Стоп-стоп, если у тебя столкнутся два авто или, еще хуже, поезда - то будет существенный экономический ущерб. > Когда это всё появилось к смертям относились сильно проще. Угу, в стиле "помер маским, ну и №№№ с ним". Некоторые до сих пор так относятся, ну типа "1% это не много". Но опускаться в средневековье хочется не всем людям) > Раст не та технология. "Та или не та" решаю не я и не ты. Те кому оно нужно будут применять, даже если тебе это не нравится. > Языков с безопасной памятью - вагон и тележка, и возрастом они все сильно старше раста. Примеры в студию. Желательно без GC. Я могу вспомнить только ровестницу C/C++ - ADA, но там надо думать, а на си - нет. > Все кому было надо - уже давно в безопасности, либо используя ЯП либо практики типа мисра. Мисра это классно, но написать что-то большое без динамических аллокаций будет очень-очень сложно. > Но теперь появились растисты и мир оказался в опасносте. Бери больше! Голактика в опасности (с)
	Ответить | Правка | Наверх | Cообщить модератору

	174. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+/–
	Сообщение от Ivan_83 (ok), 02-Окт-24, 19:59
	Вы со своей фиксацией на программных деффектах как псих который готовится к нашествию динозавров или вечно опасающийся что на него лично упадёт микрометеорит (1 зафиксированный случай за историю). А если на горизонте маячит вымирание - то стоит расслабится и занятся чем то приятным в последние дни. "Carol and the End of the World" вам в помощь для прочистки мозгов. > Ты наверное из тех, кто не против когда асфальт прямо в лужу кладут или выпускают уже ржавое ведро прямо с завода. Я из тех кто считает что стерилизация медицинским спиртом поверхности перед укладкой асфальта - излишнее действие. А если где то положат в лужу - то пусть потом по гарантии переделывают. Проблема же в том, что в РФии это не работает и по гарантии никто ничего не делает, а делает за зовые отдельные деньги потом. Был бы действующий механизм - никто бы в лужу не ложил.
	Ответить | Правка | Наверх | Cообщить модератору

	128. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+/–
	Сообщение от Аноним (128), 01-Окт-24, 00:25
	Сколько лжи в паре предложений... > Только у фанатиков есть цель победить все ошибки и уязвимости, Не все, а только 70%, но каких! Из-за которых 99% критических уязвимостей > обычным людям надо чтобы нечто работало с минимальными затратами. Так и работает с минимальными затратами и даже лучше, спроси у тех. директора гугла про разработку на расте и на плюсах (чтобы долго не искал, вот тебе коротко из речей Ларса Бергстрома: "On re-writing C++ into Rust: "in every case, we've seen a decrease by more than 2x in the amount of effort required to both build the services written in Rust, as well as maintain and update those services. [...] C++ is very expensive for us to maintain." ). > Ошибки, уязвимости - вообще не проблема ... только для тебя. Иди ты лесом, с таким подходом. Пиши дырявые хелловроты строго для селбя, любимого, для своего локалхоста и не вылезай из будки.
	Ответить | Правка | К родителю #108 | Наверх | Cообщить модератору

	137. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+/–
	Сообщение от Ivan_83 (ok), 01-Окт-24, 02:27
	Так не качайте и используйте мои хэлловорлды, тем более бесплатно, а я как писал так и буду дальше писать.
	Ответить | Правка | Наверх | Cообщить модератору

	4. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+1 +/–
	Сообщение от Аноним (4), 30-Сен-24, 09:13
	А какой справляется?
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	13. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+2 +/–
	Сообщение от Аноним (13), 30-Сен-24, 10:44
	Turbopascal)
	Ответить | Правка | Наверх | Cообщить модератору

	42. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+/–
	Сообщение от Аноним (42), 30-Сен-24, 12:42
	В нём тоже указатели можно.
	Ответить | Правка | Наверх | Cообщить модератору

	17. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	–3 +/–
	Сообщение от Аноним (-), 30-Сен-24, 10:54
	> Очевидно, язык не справляется со своими задачами. А причем тут язык? Тут проблемы в квалификации! Надо менять подходы. Например, для PR в ядро, обязать чтобы код проходил стат. анализаторы, добавить фаззинг, публично осуждать бракоделов (можно взять Линуса и дать ему затачу показывать им пальцы)
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	109. Скрыто модератором	+/–
	Сообщение от Ivan_83 (ok), 30-Сен-24, 22:46
	Точно, забюрократизировать процесс чтобы виноватых не было, не важно что работа встанет. У растоманов один из страхов - быть виноватым в ошибке, те понести отвественность за свои дела.
	Ответить | Правка | Наверх | Cообщить модератору

	23. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	–2 +/–
	Сообщение от Аноним (23), 30-Сен-24, 11:29
	А что, задача была в безопасность? Вы, когда пишете код, сильно про безопасность думаете? Что ж вы так за безопасность переживаете? Есть примеры, когда лично ваш ПК пострадал из-за дыр в безопасности? Пс. Не к вам лично вопрос, а к обществу, которое бурно реагирует на такие новости.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	30. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+/–
	Сообщение от Аноним (30), 30-Сен-24, 11:41
	> Вы, когда пишете код, сильно про безопасность думаете? думать о безопасности, задача безопасников!
	Ответить | Правка | Наверх | Cообщить модератору

	54. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+1 +/–
	Сообщение от Аноним (54), 30-Сен-24, 14:43
	У кого-то ведь в ответственности не только личные ПК с игрульками. Приходится думать.
	Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

	78. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+/–
	Сообщение от Аноним (78), 30-Сен-24, 18:20
	Да. У кого-то где-то, но не у вас. Вы-то что так бурно реагируете на новости о безопасности?
	Ответить | Правка | Наверх | Cообщить модератору

	63. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+/–
	Сообщение от YetAnotherOnanym (ok), 30-Сен-24, 15:47
	Задача всегда в безопасность. Была, есть и будет.
	Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

	80. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+/–
	Сообщение от Аноним (78), 30-Сен-24, 18:22
	Ваши вычислительные мощности как-то пострадали от дыр?
	Ответить | Правка | Наверх | Cообщить модератору

	160. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+/–
	Сообщение от YetAnotherOnanym (ok), 01-Окт-24, 15:57
	Это обязательно?
	Ответить | Правка | Наверх | Cообщить модератору

	70. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+/–
	Сообщение от Активист (?), 30-Сен-24, 16:56
	Что за обществу вы задаёте вопрос? Может быть вы задаёте его так называемому "сообществу"? Тогда я уверю вас, что стакан недостаточно полон, чтобы из него что-то выплёскивалось при бурлении.
	Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

	38. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	–1 +/–
	Сообщение от Аноним (42), 30-Сен-24, 12:34
	Надо полагать, что большинство связаны с комитерами, коих >2000 бывает. Всех не проверишь. Наверняка, есть и от организаций с трёхбуквенными названиями.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	52. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+/–
	Сообщение от Аноним (52), 30-Сен-24, 14:26
	Другой язык программирования никак не сможет проверить этих 2000 а три буквы вставят что надо на любом языке. Даже на языке жестов.
	Ответить | Правка | Наверх | Cообщить модератору

	55. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+/–
	Сообщение от Аноним (54), 30-Сен-24, 14:44
	Так сам финский студент на три буквы работает.
	Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

	71. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+/–
	Сообщение от Активист (?), 30-Сен-24, 17:02
	Да, да. Хоть Гугль то почитайте.
	Ответить | Правка | Наверх | Cообщить модератору

	100. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+1 +/–
	Сообщение от Аноним (101), 30-Сен-24, 20:49
	>язык не справляется со своими задачами Задача Си - быть кроссплатформенным языком ассемблера для написания небольших операционных систем, как Unix. На что-то другое его создатели не нацеливали. Ритчи и Томпсон сильно удивились когда на Си стали делать ОСы из миллионов строк кода.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

10. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	–2 +/–
Сообщение от Аноним (10), 30-Сен-24, 09:52
> в июньском обновлении пакета с ядром 5.10 в Debian помимо CVE-2024-26808 > было исправлено ещё 345 (!) потенциальных уязвимостей Мда... Знатное peшeто это ваше ядро. Вот что бывает, когда десятилетиями омнокодят и кладут болтяру на безопасность. Думаю что в ядре ситуация еще хуже чем в иксах))
Ответить | Правка | Наверх | Cообщить модератору

	11. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (11), 30-Сен-24, 10:21
	Надо было Hurd развивать, а не вот это вот всё.
	Ответить | Правка | Наверх | Cообщить модератору

	56. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+1 +/–
	Сообщение от Аноним (54), 30-Сен-24, 14:47
	Но к большому сожалению академические мужы оказались более тщепетмльны и медлительны, чем финский скорострел. Вышло как вышло.
	Ответить | Правка | Наверх | Cообщить модератору

	64. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (-), 30-Сен-24, 15:55
	> к большому сожалению на академических мужей подали в суд и затянулись эти суды на годы. Поэтому индустрия легкого поведения побежала за скорострелом.
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Активист (?), 30-Сен-24, 17:05
	А не то вышло бы как паровоз в 21 веке. (Я понимаю, что вам луддитам того и надо). Так фряха же есть более-менее окаменелая. Но почему-то вы туда не спешите.
	Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

	62. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (62), 30-Сен-24, 15:44
	> Надо было Hurd развивать, а не вот это вот всё. Если бы такие, как вы, принципиально отказались бы от использования небезопасных систем типа linux, и принципиально использовали бы только системы на базе хурд, то, возможно, Линус бы и задумался. Но вы ж бежите на небезопасное, делаемое тяп-ляп, которое скомпилировалось - и хорошо. Потому корпорации и не развивают хурд и подобные, а вкладываются в линукс - это проще, думать шибко не надо, и вместо программистов можно индусов нанять.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

12. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
Сообщение от Аноним (12), 30-Сен-24, 10:24
Неужели целочисленное переполнение нельзя отследить на этапе компиляции и какой-нибудь варн показать? Вроде бы проблеме сто лет в обед, а всё равно раз за разом повторяется
Ответить | Правка | Наверх | Cообщить модератору

	14. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	–1 +/–
	Сообщение от topin89 (ok), 30-Сен-24, 10:46
	Некоторую часть можно компиляторами, ещё часть статическими анализаторами можно. Большую часть только при живом запуске на тестах. Что поделаешь, программирование на C и C++ -- это хотьба на канате над пропастью. Чуть зазевался -- и лови CVE.
	Ответить | Правка | Наверх | Cообщить модератору

	20. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Денис Попов (?), 30-Сен-24, 11:24
	Еще один умник. Причем здесь язык к переполнению? Лишь бы на вентилятор набросить...
	Ответить | Правка | Наверх | Cообщить модератору

	24. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (24), 30-Сен-24, 11:31
	Очевидно, речь про работу с создаваемыми на ходу объектами. Тогда чтобы найти, нужно разобраться как работает алгоритм. ИИ может что-то и мог бы, но это пока дорого и не совсем доступно. И когда работа с памятью идёт вручную, то все недостатки ручной работы - ошибки человека. Автоматизация убирает такое. В каких-то языках автоматика присутствует. Те языки часто хейтят.
	Ответить | Правка | Наверх | Cообщить модератору

	28. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (-), 30-Сен-24, 11:35
	А при том. Берем какой-то безопасный язык, например ADA-Spark и смотрим их доку. docs.adacore.com/spark2014-docs/html/ug/en/source/overflow_modes.html Ого сколько тут всего интересного О_О Но самое главное - однозначного! Тут нет сишного овна типа "мы тут хз как сложить два числа, пусть компилятор думает, он же умный" с последущим UB.
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	44. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (52), 30-Сен-24, 12:44
	Только ты забыл упомянуть что ада тормозит.
	Ответить | Правка | Наверх | Cообщить модератору

	49. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (-), 30-Сен-24, 14:01
	> Только ты забыл упомянуть что ада тормозит. Так тебе тормоза или "рут всем и пусть никто не уйдет обиженным" ? Нафига вообще какие-то пароли, попытки изоляции и прочее, если нам главное "шобы побыстрее". Если тормозит - просто возьмо процессор помощнее, как говорил Тодд.
	Ответить | Правка | Наверх | Cообщить модератору

	67. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (52), 30-Сен-24, 16:27
	Давай тогда все на питоне будем писать тогда. Раз не торопимся. Зачем ада.
	Ответить | Правка | Наверх | Cообщить модератору

	97. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+1 +/–
	Сообщение от Mister (??), 30-Сен-24, 19:34
	Используй тогда gmplib никакого переполнения не будет Если где-то gmplib и что-то подобное встроено по умолчанию, то это не значит, что так надо везде Ещё можешь флаг процессора на переполнение проверять после каждой операции
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	112. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Ivan_83 (ok), 30-Сен-24, 22:50
	Потому что С не заморачивается такой фигнёй, он транслирует это в машинные инструкции, и как оно там на конкретном железе реализовано его не сильно колышит.
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	16. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (16), 30-Сен-24, 10:52
	> на этапе компиляции и какой-нибудь варн показать Разработчики на Rust сейчас: ты не поверишь!
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	19. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (12), 30-Сен-24, 11:22
	А что в расте? Там варн? Или не даёт скомпилировать, пока явно не защитишься от переполнения? (я не знаком с растом)
	Ответить | Правка | Наверх | Cообщить модератору

	21. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (21), 30-Сен-24, 11:27
	А что на раст? Там каждое сложение проверяется на переполнение на этапе конь-эпиляции?
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	22. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Денис Попов (?), 30-Сен-24, 11:29
	Не поверю. Человек должен решать, т.к. иногда именно отсутствия обработки переполнения и ожидается
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	34. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+2 +/–
	Сообщение от Аноним (52), 30-Сен-24, 11:55
	За храстовиков все должен решать храст.
	Ответить | Правка | Наверх | Cообщить модератору

	37. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+1 +/–
	Сообщение от Аноним (-), 30-Сен-24, 12:27
	100% Поэтому в языки добавили saturating_add, wrapping_add, overflowing_add, std::add_sat и другие аналогичные операции, которые будут гарантировано давать поведение, нужное разработчику в данном месте.
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	48. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (52), 30-Сен-24, 13:42
	Языки не нужны код должны писать нейросети.
	Ответить | Правка | Наверх | Cообщить модератору

	58. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (54), 30-Сен-24, 14:50
	Ваша профессия тем более, её должны выполнять автоматы/роботы.
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+3 +/–
	Сообщение от Аноним (52), 30-Сен-24, 14:59
	Нейросети должны писать код для роботов так наступит сингу... Апокалипсис.
	Ответить | Правка | Наверх | Cообщить модератору

	25. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (-), 30-Сен-24, 11:32
	> Неужели целочисленное переполнение нельзя отследить на этапе компиляции и какой-нибудь варн показать? Так основная проблема не с самим переполнением, а с тем, что его результат напр. используется как индекс. И оно пишет непонятно куда, портит память, дарит рут. Плюс переполнение signed вообще UB, т.е. одно и тоже переполнение может на разных компиляторах, с разными флагами давать разные результат. В "других языках"(с) поведение для signed переполнения зафиксировано. А от попытки писать хз куда защищают другие механизмы. Плюс можно включить проверку в релизе используя опцию overflow-checks (в дебаге она и так включена, но можно выключить при желании)
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	173. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (173), 02-Окт-24, 13:43
	> а с тем, что его результат напр. вы же приводите конкретный пример поведения, я не могу понять, что ту неопределенного? У любого действия машины вполне определенное состояние, ибо машина Тьюринга в любой момент времени находится в соответствующем состоянии, и все эти состояния детерминированы. UB это чушь стандарта, это тупо не удосужились строго описать то или иное состояние.
	Ответить | Правка | Наверх | Cообщить модератору

	27. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+2 +/–
	Сообщение от Аноним (52), 30-Сен-24, 11:34
	Даже раст в продовой сборке не спасает от переполнения.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	29. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	–1 +/–
	Сообщение от Аноним (-), 30-Сен-24, 11:39
	Что значит "не спасет"?. Переполнение это обычное поведение. Проблема не в переполнении, а в том что происходит после - т.е порча памяти и рут. Пусть она выдает неверный результат - найдем на тестах (хаха, если они у нас есть) или фаззинге. Пусть программа падает - получим логи, исправим ошибку. Но по тихому сломаться и сделать CVE - от такого точно не должно быть.
	Ответить | Правка | Наверх | Cообщить модератору

	32. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+1 +/–
	Сообщение от Аноним (12), 30-Сен-24, 11:49
	А от записи за пределы буфера спасёт?
	Ответить | Правка | Наверх | Cообщить модератору

	35. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (-), 30-Сен-24, 12:19
	> А от записи за пределы буфера спасёт? Да, вот от этого спасет. Проверки на выход за границы есть в релизе по умолчанию.
	Ответить | Правка | Наверх | Cообщить модератору

	36. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	–2 +/–
	Сообщение от Аноним (12), 30-Сен-24, 12:23
	Получается действительно хороший инструмент, что бы хейтеры не говорили
	Ответить | Правка | Наверх | Cообщить модератору

	95. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (52), 30-Сен-24, 19:28
	Нет плохой.
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (12), 30-Сен-24, 19:31
	Почему?
	Ответить | Правка | Наверх | Cообщить модератору

	122. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (111), 30-Сен-24, 23:28
	Вопрос простой и наивный, но ... на все вопросы не будет ответа, надо самому прийти к ответу
	Ответить | Правка | Наверх | Cообщить модератору

	150. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (52), 01-Окт-24, 12:57
	Потому что раст создаёт большие проблемы чем якобы решает. А не решает потому что без ансейф раст на низком уровне где он в теории мог быть  нужен в принципе ничего решить не может.
	Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

	33. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (52), 30-Сен-24, 11:54
	На Си тоже самое так что раст не надобен.
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	65. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (65), 30-Сен-24, 16:13
	Спасает, если использовать функции вместо оператора +
	Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

	175. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (175), 03-Окт-24, 20:47
	Так и на Си так можно. Вот и выходит, что Раст не нужен, как ни крути.
	Ответить | Правка | Наверх | Cообщить модератору

	110. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Ivan_83 (ok), 30-Сен-24, 22:47
	Нельзя. Данные для сложения/умножения можно прочитать из файла или получить по сети.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

68. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	–2 +/–
Сообщение от Аноним (68), 30-Сен-24, 16:38
> вызвана недостаточной проверкой границ буфера Есть два типа программистов на Си: первые не проверяют границы буферов, вторые проверяют, но недостаточно. Пожалуй, это всё, что нужно знать о культуре разработки на этом языке.
Ответить | Правка | Наверх | Cообщить модератору

	74. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+1 +/–
	Сообщение от Ivan_83 (ok), 30-Сен-24, 17:41
	Таки приходите когда на вашем чуднОм языке будет написано хотя 0,001% от того что написано на С, и это будут не вариации хэлло ворлда и прочих прог на 10 строк а нечто на 50к+ строк.
	Ответить | Правка | Наверх | Cообщить модератору

	77. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	–3 +/–
	Сообщение от Аноним (12), 30-Сен-24, 18:12
	Над аргументом "сперва добейся" в интернете ещё двадцать лет назад смеялись
	Ответить | Правка | Наверх | Cообщить модератору

	104. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Минона (ok), 30-Сен-24, 21:52
	От чего и выросло поколение не знающее матчасть.
	Ответить | Правка | Наверх | Cообщить модератору

	176. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (175), 03-Окт-24, 20:49
	А сейчас смеются над аргументом "сперва выучи язык, а потом его критикуй".
	Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

	79. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	–1 +/–
	Сообщение от Аноним (68), 30-Сен-24, 18:21
	> на вашем чуднОм языке Это на каком же именно? И при чём тут другие языки к Си? Факт остаётся фактом: сишные кодеры в целом, как культурное явление, не смогли за пятьдесят лет решить типичные проблемы с менеджментом памяти.
	Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

	89. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от _ (??), 30-Сен-24, 18:53
	Факт остаётся фактом: никто другой ниасилил массовое, популярное, производительное и (sic!!!) достаточно безопасное (да-да!!) ядро. Это ж вам не чистые функции в вакууме, это ж по локоть в мазуте в железных потрохах ковыряться  :( Поэтому возьмите свои замечательные и классные языки, без всяких там подколов - замечательные и классные!, и идите ка в свой юзерланд. Как добрый старый дяденька вам советую :)
	Ответить | Правка | Наверх | Cообщить модератору

	91. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (68), 30-Сен-24, 19:07
	Ядро, мазут, локти — это всё понятно, к объективной реальности несовершенства оборудования вопросов нет. Почему память пятьдесят лет течёт и перезаписывается из-за буквально одних и тех же ошибок, и когда это будет исправлено на уровне культуры разработки (про тулинг и стандарт даже не спрашиваю)?
	Ответить | Правка | Наверх | Cообщить модератору

	94. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (52), 30-Сен-24, 19:28
	Все исправляется по мире нахождения. Используй друг языки кто тебе мешает?
	Ответить | Правка | Наверх | Cообщить модератору

	98. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	–1 +/–
	Сообщение от Аноним (68), 30-Сен-24, 20:06
	Мне никто не мешает. Проблема не в моих возможностях, а в плачевном состоянии гигиены в сообществе кодеров на Си.
	Ответить | Правка | Наверх | Cообщить модератору

	148. Скрыто модератором	+/–
	Сообщение от Аноним (52), 01-Окт-24, 12:50
	Это только в твоём воображении по существу нечего сказать.
	Ответить | Правка | Наверх | Cообщить модератору

	102. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	–1 +/–
	Сообщение от Аноним (-), 30-Сен-24, 21:11
	> Все исправляется по мире нахождения. Вот жаль что врачи так не работают, да? "Ой, кажется пила случайно вышла за границы черепа и мы отпилили пациенту мозг... Ну ничего, тут держалку подправим, и возможно в следующий раз повезет" Тесты? Зачем! Мы тут все профи. > Используй друг языки кто тебе мешает? Диды мешают. Всеми силами копротивляются добавлению раста в ядро. Не хотят просто лишиться работы по исправлению и добавлению уязвимостей)
	Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

	123. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+1 +/–
	Сообщение от Аноним (123), 30-Сен-24, 23:41
	> Ой, кажется пила случайно вышла за границы черепа и мы отпилили пациенту мозг... Тебе переполнением буфера мозг задело? > Диды мешают. Всеми силами копротивляются добавлению раста в ядро. да никто вам не мешает, вы просто делать этого не хотите и/или не умеете. Форкаете репозиторий и пишите в него на расте, но нет... OpenVZ тянули свои патчи и их не останавливало, что они не в мэйнлайне. wireguard переделывали несколько раз, чтобы приняли. openvpn озадачился своим модулем -- тоже не в ядре ntfs от paragon не хотели принимать, т.к. боялись, что никто не будет поддерживать. zfs даже не светит в ядре оказаться, но его все равно пишут. uksm и прочие патчи тянули или тянут насколько хватает сил и интереса. И только расту диды мишают настолько, что даже форкать страшно
	Ответить | Правка | Наверх | Cообщить модератору

	117. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+1 +/–
	Сообщение от Ivan_83 (ok), 30-Сен-24, 23:00
	А вы errata интела, амд и прочих чипмейкеров хоть когда то читали? Впрочем что взять с людей свято верующих что раст им может гарантировать безопасную работу с памятью, и сидящих на системах без ECC, где ровхаммер жабаскриптом из браузера делается.
	Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

	131. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (128), 01-Окт-24, 01:14
	> Впрочем что взять с людей свято верующих что раст им может гарантировать безопасную работу с памятью У гугловцев к 2022-му году (отчет на тот момент) после пары лет внедрения и использования раста в андроиде, в 1.5 млн строк нового системного кода на расте не всплыло ни одной ошибки работы с памятью. Ни одной, Карл, в полутора миллионах строк кода! Цитата из отчета: "...To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code..." И это за два релиза андроида! "We don’t expect that number to stay zero forever, but given the volume of new Rust code across two Android releases, and the security-sensitive components where it’s being used, it’s a significant result." Но надо верить Ване_с_Опеннета, а не гуглу.
	Ответить | Правка | Наверх | Cообщить модератору

	132. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Ivan_83 (ok), 01-Окт-24, 02:14
	Новый это то что осталось или сумма со всех гит коммитов, а то может полтора ляма добавили и два убрали. А вы уже научились собирать андройд на убунте или это уже задача чересчур сложная? (так чтобы без докеров от гугла и прочих комманд)
	Ответить | Правка | Наверх | Cообщить модератору

	149. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+1 +/–
	Сообщение от Аноним (52), 01-Окт-24, 12:53
	Этот самый гугл который в хроме ничего кроме генерации qr кода ничего больше не осилил?
	Ответить | Правка | К родителю #131 | Наверх | Cообщить модератору

	156. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (128), 01-Окт-24, 13:39
	Ему про полтора миллиона строк кода без единой уязвимости по памяти в андроиде, а он про "ниасилили" что-то в хроме. Вот из-за людей с таким логическим складом в голове мы и имеем тонны CVE-шек. > Этот самый гугл который в хроме ничего кроме генерации qr кода ничего больше не осилил? Рискну предположить, что в отличие от андроида, за раст в хроме еще толком и не брались, чтобы успеть там что-то "ниасилить". И предположу дальше - гугл следует своей же заявленной стратегии - старый сишный/плюсовый код оставить и просто фиксить, а новый писать на расте или переписывать ну очень ответственные по безопасности куски, в которых вечно ошибки вылазили, типа какого-нибудь стека блютуз. И еще предположу - гугловцев больше интересует просовываине ржавого в дырявое линукс-ядро (они робко заикались парой предложений и про такое в своем отчете), чем переписывать на ржавом в целом сильно вылизанный и причесанный хром.
	Ответить | Правка | Наверх | Cообщить модератору

	161. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (-), 01-Окт-24, 15:57
	> И еще предположу - гугловцев больше интересует просовываине ржавого в дырявое линукс-ядро (они робко заикались парой предложений и про такое в своем отчете), чем переписывать на ржавом в целом сильно вылизанный и причесанный хром. Хм, но зачем? Гугл от ядра зависит, но не так сильно как какая нибудь ИБМ (красношапка). Да, по хорошему сами разрабы ядра должны были бы хотеть улучшить ядро))
	Ответить | Правка | Наверх | Cообщить модератору

	115. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Ivan_83 (ok), 30-Сен-24, 22:57
	У вас шизофрения какой стадии? В диагнозе я не сомневаюсь: вы упорно отрицаете реальность в которой подавляющее большинство написано на С само или написано на производном от С продукте, работает на ОС которые написаны на С - других просто не существует (кроме как музейных экспонатов в виртуалке). Ни один другой язык не даёт простой и понятный API для линковки с другими языками.
	Ответить | Правка | К родителю #79 | Наверх | Cообщить модератору

	124. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (12), 30-Сен-24, 23:49
	Вы бы сами проверились что ли… Вам про Фому, вы про Ерёму. 68-й вам пишет: Сишники пятьдесят лет подряд пишут мимо буфера, а вы ему в ответ «да ты погляди вокруг всё написано на Си». А кто с этим спорил-то? На Си и пишут мимо буфера, как и было сказано.
	Ответить | Правка | Наверх | Cообщить модератору

	133. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Ivan_83 (ok), 01-Окт-24, 02:15
	Так а в чём проблема то? Это же всё работает и используется.
	Ответить | Правка | Наверх | Cообщить модератору

	125. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	–1 +/–
	Сообщение от Аноним (-), 01-Окт-24, 00:20
	> У вас шизофрения какой стадии? > В диагнозе я не сомневаюсь: О, так ты не только программист, но еще и психиатр? А случайно "для души" не таксуете? > вы упорно отрицаете реальность в которой подавляющее большинство написано на С само или написано на производном от С  продукте, работает на ОС которые написаны на С - других просто не существует (кроме как музейных экспонатов в виртуалке). Нет, я эту рельность вижу (хотя винда написана на плюсах). Но то что у нас есть реликты прошлого не повод за них цепляться. Весь современный мир построен рабским трудом. Все эти пирамиды, греческие и римские храмы, готические соборы и даже американские плантации. Но это не повод сейчас вводить новое крепостное право. > Ни один другой язык не даёт простой и понятный API для линковки с другими языками. И настолько легких уязвимостей.
	Ответить | Правка | К родителю #115 | Наверх | Cообщить модератору

	134. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+1 +/–
	Сообщение от Ivan_83 (ok), 01-Окт-24, 02:19
	Раст не замена С и даже близко к этому не подошёл, максимум он конкурент (слабенький) плюсам. Одной якобы безопасной работы с памятью и синтаксического сахара для многопоточности очень мало чтобы метить в "системные" ЯП.
	Ответить | Правка | Наверх | Cообщить модератору

	158. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (68), 01-Окт-24, 15:35
	Да забудь ты про раст, что он тебе всё покоя не даёт? Очевидно, что выкинуть весь сишный код и переписать его на другом языке нереально. Очевидно так же, что никакой другой язык не способен исправить генетические проблемы Си. Вопрос остаётся всё тем же: почему культура разработки на Си такая ужасная, что кодеры пятьдесят лет делают одни и те же — буквально! — ошибки и как это исправить?
	Ответить | Правка | Наверх | Cообщить модератору

	164. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Ivan_83 (ok), 01-Окт-24, 22:11
	А почему вы думаете что это надо исправлять? ) Вот серьёзно. Ошибки в коде слишком редкие и слишком мало мешаются чтобы быть проблемой которую надо решать чтобы получить хоть какой то профит. Факапы типа как с краудстрайком - слишком редкие, а всё остальное - это шум админов в курилке и не более.
	Ответить | Правка | Наверх | Cообщить модератору

	177. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (175), 03-Окт-24, 20:55
	ИИ сможет исправить, тогда про ошибки с памятью в Си можно будет забыть. И про Раст тоже.
	Ответить | Правка | К родителю #158 | Наверх | Cообщить модератору

99. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
Сообщение от Аноним (101), 30-Сен-24, 20:40
>вызвана недостаточной проверкой границ буфера ... > ... >вызваны обращением к уже освобождённой области Меня всегда удивляют подобные сообщения об ошибках, откуда они, кто их сделал, почему? На C и C++ программирую с 18 лет, у меня никогда не было подобных ошибок. У коллег тоже не замечал. Ошибки бывают с синхронизацией потоков, с обработкой исключений, из-за недонажатия клавиш при наборе текста, но с памятью - никогда.
Ответить | Правка | Наверх | Cообщить модератору

	106. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (68), 30-Сен-24, 22:13
	Ну тут одно из двух: либо ты с коллегами решаешь тривиальные задачи не требующие сложного менеджмена памяти, либо просто врёшь.
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (111), 30-Сен-24, 22:59
	Да, программы на С были небольшие, несколько драйверов и несколько управляющих программ для встроенных систем по 10-15 тыс. строк кода, но всё же
	Ответить | Правка | Наверх | Cообщить модератору

	159. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (68), 01-Окт-24, 15:47
	> несколько драйверов и несколько управляющих программ для встроенных систем Как я и сказал, тривиальные задачи. Тут действительно довольно сложно налажать с управлением памятью.
	Ответить | Правка | Наверх | Cообщить модератору

	119. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Ivan_83 (ok), 30-Сен-24, 23:07
	Почти все задачи могут быть сведены к примитивному манагементу памяти, просто некоторые люди сильно злоупотребляют malloc()/free().
	Ответить | Правка | К родителю #106 | Наверх | Cообщить модератору

	118. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Ivan_83 (ok), 30-Сен-24, 23:05
	В просто плохо тестировали :) Я тут как то писал парсер proxy proto обоих версий, и как то неожиданно много спотылкался на такой то примитивной задаче, что выяснилось когда я сам же себя ревьювил. С памятью бывают ошибки вида: маловато памяти выделил или немножко не туда записал, ASAN прекрасно такое ловит, главное дать ему такую возможность.
	Ответить | Правка | К родителю #99 | Наверх | Cообщить модератору

	121. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (-), 30-Сен-24, 23:26
	> ASAN прекрасно такое ловит ASAN ловит только тривиальные случаи. Которые вы вряд ли допустите. А когда для повторения нужны "специально оформленные данные", то толку от ASAN практически нет.
	Ответить | Правка | Наверх | Cообщить модератору

	135. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Ivan_83 (ok), 01-Окт-24, 02:20
	Для этого фазинг придумали. Нет, он вполне себе много всего ловит, и не тривиального тоже.
	Ответить | Правка | Наверх | Cообщить модератору

	165. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (-), 01-Окт-24, 22:59
	> ASAN ловит только тривиальные случаи. Которые вы вряд ли допустите. > А когда для повторения нужны "специально оформленные данные", то толку от ASAN > практически нет. Почему же. Если все время под asan гонять - он поймает. А так то CVE и на хрусте можно вкатить. Вон там чудный crate который CVE делает исключительно safe кодом :)
	Ответить | Правка | К родителю #121 | Наверх | Cообщить модератору

	130. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (128), 01-Окт-24, 00:57
	> На C и C++ программирую с 18 лет "... и завтра мне исполнится 19!". Чтобы аргументировать свой опыт стажем нужно или текущий возраст указать (чтобы вычесть 18 лет) или просто назвать стаж программирования. Но вообще глупо и наивно к стажу апеллировать, ведь от человека и от решаемых задач зависит - один за 2 года добъется бОльшего, чем иной за 40 лет или один годами json-ы перекладывает или простые алгоритмы в контроллеры пихает, а другой базы данных нового типа придумывает или востребованные операционки пишет. А про отсутствие ошибок... Это эффект Неуловимого Джо. Вы объявИте награду за найденные уязвимости в ваших поделках, как когда-то сделал Дэниел Бернштейн или как сегодня практикуют всякие гуглы, устраивая баг-баунти. Не найдут дыр - тогда и хвалитесь.
	Ответить | Правка | К родителю #99 | Наверх | Cообщить модератору

141. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+1 +/–
Сообщение от мяв (?), 01-Окт-24, 07:26
идет 3й год, а софтверных уязвимостей, способных сделать хоть что-то с моим десктопом/сервером - все так же (почти?) нет. потому что tomoyo!
Ответить | Правка | Наверх | Cообщить модератору

	142. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от мяв (?), 01-Окт-24, 07:30
	думала, кстати, попробовать портировать akari(реализуцию tomoyo, не использующую LSM) под freebsd. после быстрого ресерча, оказалось, что это не так уж и сложно. возможно, займусь в отпуске. тогда можно будет и некоторые ограничения обойти(например, добавить неогран. кол-во acl-групп с именами в тексте).
	Ответить | Правка | Наверх | Cообщить модератору

	144. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Ivan_83 (ok), 01-Окт-24, 09:29
	А зачем? Есть же MAC для любителей везде ограничивать и проверять.
	Ответить | Правка | Наверх | Cообщить модератору

	145. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от мяв (?), 01-Окт-24, 11:06
	path-based MAC'ов и тем более, MAC'ов, способных индивидуально под систему политики генерить, почти без участия пользователя - нет.
	Ответить | Правка | Наверх | Cообщить модератору

	162. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Ivan_83 (ok), 01-Окт-24, 21:26
	Там легко накорябать любой свой MAC. Я так 1-2 модуля накорябал чтобы без рута давало отдельные штуки делать, кажется для сырых сокетов не руту.
	Ответить | Правка | Наверх | Cообщить модератору

	169. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	–1 +/–
	Сообщение от мяв (?), 01-Окт-24, 23:52
	зачем изобретать велосипед? и да, Вы не МАС описали, а CAP_NET_RAW.
	Ответить | Правка | Наверх | Cообщить модератору

	170. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+1 +/–
	Сообщение от Ivan_83 (ok), 02-Окт-24, 02:02
	А я и не хотел описывать мандатный контроль доступа, хотя то что я сделал можно назвать вырожденным частным случаем оного ибо всем стало можно :) Там чуть больше: static int allow_socket_priv_grant(struct ucred *cred, int priv) {     if (!allow_socket_enabled)         return (EPERM);     switch (priv) {     case PRIV_NETINET_RESERVEDPORT:     case PRIV_NETINET_RAW:     case PRIV_NETINET_REUSEPORT:     case PRIV_NETINET_BINDANY:         return (0);     default:         break;     }     return (EPERM); } static struct mac_policy_ops allow_socket_ops = {     .mpo_priv_grant = allow_socket_priv_grant }; MAC_POLICY_SET(&allow_socket_ops, mac_allow_socket,     "MAC/allow_socket", MPC_LOADTIME_FLAG_UNLOADOK, NULL); Это практически весь модуль, без чтения sysctl параметра allow_socket_enabled и инклюдов с лицензией. Практически такой же модуль я делал для chroot от юзера, уже даже не помню зачем. И собственно моё предложение посмотреть в сторону MAC было потому что там есть всё нужное и этим легко пользоватся: можно сразу начать писать "бизнесс логику" не рыская по ядру в поисках куда бы приткнутся и не заморачиваясь тем что при обновлении системы нужно будет ребейзить свой патч каждый раз.
	Ответить | Правка | Наверх | Cообщить модератору

	171. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от мяв (?), 02-Окт-24, 10:49
	хм.. интересно. надо бы по их докам поподробнее посмотреть. спасибо!
	Ответить | Правка | Наверх | Cообщить модератору

	167. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (-), 01-Окт-24, 23:04
	> path-based MAC'ов и тем более, MAC'ов, способных индивидуально под систему политики генерить, > почти без участия пользователя - нет. Вам не приходило в голову что если чего-то нет и это относительно просто напрогать - то тогда это скорее всего потому что такое комбо просто лишено практического смысла? Все эти ACL, модули и безопасности и проч имеют кое что общее. С одной стороны, админу их сложно и канительно настраивать. С другой - из эксплойтов все ваши жалкие потуги вырубаются просто влет. Ну они в силу таких соотношений и не популярны у прагматиков. Ведь по хорошему гиморно должно быть атакующим, а удобно - админам. А у вас все наоборот по сути.
	Ответить | Правка | К родителю #145 | Наверх | Cообщить модератору

	166. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (-), 01-Окт-24, 23:02
	> думала, кстати, попробовать портировать akari(реализуцию tomoyo, не использующую LSM) > под freebsd. после быстрого ресерча, оказалось, что это не так уж и сложно. > возможно, займусь в отпуске. Остался только вопрос - а зачем это все? Изоляция контейнерами и виртуалками 1) Радикальнее и спасает от большего числа факапов. 2) Многократно проще в реализации. Собственно поэтому ими все и пользуются, а вон те - удел каких-то странных личностей. А какая-нибудь рутковска делает, вот, таки, CubeOS.
	Ответить | Правка | К родителю #142 | Наверх | Cообщить модератору

	168. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от мяв (?), 01-Окт-24, 23:49
	1) виртуализация открывает некоторые дыры в ядре 2) Вас кто от факапов виртуалки спасет? кто от факапов инита, всех 100500 компонентов de и еще кучи системнмых сервисов? >а вон те - удел каких-то странных личностей а вот это - фантазии анонима с опеннета. что-то не вижу я в rhel/debian/ubuntu "контейнеров и виртуализации" из коробки. а MAC - пожалуйста. Выше, вон, еще человек писал, мол "такая связка лишена смысла". видимо, тоже дальше домашнего компа не смотрел и про принцип работы ids не в курсе.
	Ответить | Правка | Наверх | Cообщить модератору

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

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