https://opennet.ru/openforum/vsluhforumID3/122254.html В OpenBSD устранена уязвимость в IPv6-стеке, которая может привести к использованию уже освобождённой области памяти mbuf (use-after-free) в процессе генерации ICMP6-ответа на пакет IPv6....<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=53985<br> https://opennet.ru/openforum/vsluhforumID3/122254.html#88 Sun, 22 Nov 2020 17:52:08 GMT ботнетом они и так становятся, наставив апкшек от неПети, а кирпич вообще проблемы юзерей, с другой стороны оборудование для nat не бесплатное и требует обсдуги и электричества, однажды будет соблазн просто утилизировать это<br> https://opennet.ru/openforum/vsluhforumID3/122254.html#87 Sun, 22 Nov 2020 17:49:03 GMT правильно, должен же кто-то за "дефицитные" ipv4 платить, всего 2 бакса в месяц за право аренды 4 байтов и они ваши - а что поделать, байтов на всех не хватает, поразвели компьютеров и мобил, понимаешь<br> https://opennet.ru/openforum/vsluhforumID3/122254.html#86 Sat, 21 Nov 2020 17:45:56 GMT ping of the death? опять? на чужих ошибках учиться не того? почему это сейчас, а не 10 лет назад то? это первый кто код ipv6 в bsd прочитал?<br> https://opennet.ru/openforum/vsluhforumID3/122254.html#84 Sun, 01 Nov 2020 15:10:56 GMT &gt; Они не любят PaX & Grsecurity<br><br>Они - это кто? Линус и Шпенглер? Ничего, что Brad Spengler - это как раз из grsec?)<br><br>&gt; сделана хуже чем в оригинальном PaX & Grsecurity.<br><br>А обосновать почему PAX_SECSTACK им. Попова из Ptsecurity хуже оригинального своими словами рассказать сможешь?)<br><br>&gt; JIT - зло и надо во всех программах иметь опцию configure --jitless --no-jit для сборки проги без JIT.<br><br>Жаль, что ты не способен понимать даже то, что ты сам пишешь. Ну зачем делать опции "jitless", если jit вообще не нужен?<br>По существу: нет, не надо.<br><br>&gt; может дать гарантии<br><br>О, ты пошёл очередной круг нарезать. Я сливаюсь, у меня уже и так отпечаток ладони на лице который день болит.<br> https://opennet.ru/openforum/vsluhforumID3/122254.html#83 Sun, 01 Nov 2020 14:02:44 GMT &gt; Его тоже прекрасно трахают. И работает он также <br><br>Так он и должен трахаться, в этом вся суть.<br> https://opennet.ru/openforum/vsluhforumID3/122254.html#82 Sun, 01 Nov 2020 13:44:31 GMT &gt; В свободном ПО есть возможность независимой верификации. Средства контроля просты.<br><br>И поэтому постоянно находят всё новые и новые ошибки, наберите воздуха, готовы? переполнения буфера.<br><br>&gt; Исходя из темы обсуждения привет надо передавать Intel NX.<br><br>Да всему этому x86/RISC цирку нужно привет передавать.<br><br>&gt; SecureBOOT, TPM - хорошие вещи.<br><br>Для ограничения свободы пользователей.<br><br>&gt; Компилять только на отключенных от сети компах.<br><br>Как это поможет с концептуальными недостатками сишки?<br><br>&gt; Система повторяемые сборок для верификации бинарей.<br><br>Это далеко не все линуксы освоили для ядра хотя бы.<br>Это хорошо конечно всё и замечательно.<br>Но что-то с индустрией принципиально не так если требуются титанические усилия для создания системы повторяемой сборки.<br>Вообще, кроме GuixSD кто-то это из линуксов обеспечивает?<br><br>&gt; Им и знать не надо. YAMA в ядре Linux знает.<br><br>You known nothing, YAMA Linux.<br> https://opennet.ru/openforum/vsluhforumID3/122254.html#81 Sun, 01 Nov 2020 05:35:04 GMT &gt; Профессионализм программистов<br><br>Компилятор с хорошими опциями компиляции укажет программисту на ошибки безопасности.<br><br>Вот профессионализм проявляется тогда когда программист сам исправляет ошибки по рекомендации компилятора. Когда исправляет после багрепорта тоже еще можно терпеть.<br><br>&gt; портирование ядерной защиты на другую архитектуру будет неадекватно сложно.<br><br>Это тема большого отдельного разговора. По этому поводу я согласен с Н. Виртом.<br><br>&gt; высказывания линуса и шпенглера по поводу этих патчей <br><br>Они не любят PaX & Grsecurity и противятся включению этих патчей в ядро уже 20 лет. То что включается в ядро, не все но часть дырява и сделана хуже чем в оригинальном PaX & Grsecurity.<br><br>&gt; У тебя какая-то болезненая фиксация на jit. <br><br>Да, причем очень заостренная. Иначе пионеры этот JIT напихают во весь софт. У меня строгая реализация защиты не допускающая любого JIT, соответственно ПО которое не собирается без JIT у меня и на многих архитектура процессоров mips, ppc, ... просто не будет работать. Мы не м https://opennet.ru/openforum/vsluhforumID3/122254.html#80 Sun, 01 Nov 2020 05:12:55 GMT &gt; Ну например уязвимости в средствах контроля.<br><br>В свободном ПО есть возможность независимой верификации. Средства контроля просты.<br><br>&gt; Привет интелME.<br><br>Исходя из темы обсуждения привет надо передавать Intel NX. Проблемы с этой инструкцией уже были в ранних версия Pentium4. Есть вариант чисто программой защиты, без использования специальных инструкций процессора, на пару процентов снизит производительность.<br><br>&gt; Привет секурбут.<br><br>SecureBOOT, TPM - хорошие вещи. Производителям кроме верификации по цифровым подписям стоит добавить на платы джемпер физически запрещающий запись в SPI где хранится UEFI/BIOS.<br><br>&gt; Ну а дальше системные неустранимые недостатки, вроде Си процессоров в которых ни о каком контроле и речи не идет <br><br>Компилять только на отключенных от сети компах.<br><br>Система повторяемые сборок для верификации бинарей.<br><br>&gt; Си программ которые тоже ничего о разделении памяти не знают.<br><br>Им и знать не надо. YAMA в ядре Linux знает.<br> https://opennet.ru/openforum/vsluhforumID3/122254.html#79 Sat, 31 Oct 2020 20:22:38 GMT &gt; Как это оправдывает опенбсд?<br><br>От чего оправдывает? Кто-то в чем-то обвиняет OpenBSD?<br>Мы тут на суде?<br>