https://www.solaris.opennet.ru/openforum/vsluhforumID3/108556.html Разработчики системы Triforce (https://www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2016/june/project-triforce-run-afl-on-everything/), созданной для fuzzing-тестировния системных вызовов ядра Linux, адаптировали свой инструмент для других систем и провели проверку ядра OpenBSD. В результате проверки в ядре OpenBSD было выявлено (http://openwall.com/lists/oss-security/2016/07/14/5) пять уязвимостей, которые могут использоваться для инициирования отказа в обслуживании через вызов краха ядра после определённых манипуляций со стороны непривилегированного пользователя. Ещё две проблемы могут эксплуатироваться пользователями, которым предоставлено право монтирования накопителей. <br><br><br><br><br>Проблемы присутствуют в системных вызовах mmap, kevent, __thrsleep, __thrsigdivert и getdents, а также в реализации файловой системы tmpfs и коде отмонтирования ФС. Для всех уязвимостей подготовлены (http://seclists.org/oss-sec/2016/q3/68) рабочие прототипы эксплоитов. Анализ наличия других векторов атаки, способны https://www.solaris.opennet.ru/openforum/vsluhforumID3/108556.html#171 Sat, 30 Jul 2016 19:16:46 GMT &gt; Потому что большая часть этих методик нацелена на охоту на ошибки. Человеческие. <br>&gt; А не надрачивание на ЯПы как серебряные пули.<br><br>С каких пор? Языки разрабатываются и совершенствуются в том числе для поиска человеческих ошибок. А мир серебряных пуль и осиновых кольев - это мифический мир фанатиков с любой стороны. И тех, что уверены будто могут создать нечто подобное и тех, что любое действие по совершенствованию заведомо объявляют "задрачиванием".<br><br>&gt; И, конечно же, ты покажешь статистику по качеству кода и количеству багов? <br><br>Несмотря на сложность статистичекого сравнения разных языков в серьёзных проектах, такое исследование было проведено для Си и Ада и было опубликовано в 1995. Найти его не составляет труда, но не думаю, что оно может быть Вам полезно, о чём говорит то самодовольство с которым был задан этот "риторический" вопрос. <br><br>Кроме того, инженер отличается от амёбы тем, что способен анализировать и моделировать, а не только пропускать через пищеварительную систему.<br><br>&gt; Для сей за все эти https://www.solaris.opennet.ru/openforum/vsluhforumID3/108556.html#170 Fri, 29 Jul 2016 04:31:10 GMT &gt; Почему Вы не включаете в методики разработки язык программирования? Это его важная часть.<br><br>Потому что большая часть этих методик нацелена на охоту на ошибки. Человеческие. А не надрачивание на ЯПы как серебряные пули.<br><br>&gt; Всё время повторяю одно и то же, разница есть в количестве ошибок,<br>&gt; пропущенных автоматическими средствами. <br><br>И, конечно же, ты покажешь статистику по качеству кода и количеству багов? И это, а анализаторы кода для rust вообще уже есть? Типовые ошибки уже осознаны? И все такое? Или это будет из разряда "вот вы на своем проекте и попробуйте набить шишек"? Для сей за все эти десятилетия типовые проблемы были изучены и появилось немало приличных тулзов всех мастей определяющих подозрительные места в коде.<br><br>&gt; Если Вы не верите в эту разницу, попробуйте программировать всё в машинных кодах,<br><br>Я пробовал программировать машины в кодах. И могу заассемблить на тетрадном листочке по даташиту. А ты это вообще умеешь? Или это тоже голое теоретизирование?<br><br>Вообще, в современных многозадачках https://www.solaris.opennet.ru/openforum/vsluhforumID3/108556.html#169 Thu, 28 Jul 2016 19:17:48 GMT &gt; Плюсы он, определенно, не заменит.<br><br>Надо уточнить - для задач Google заменит.<br><br>&gt; Хотя-бы потому что там GC вырубить нельзя, <br>&gt; насколько я помню. Это гарантирует веселые лаги в неудачном раскладе и <br>&gt; все что связано с реальным временем идет лесом.<br><br>Go был спроектирован лучше Java - если не безобразничать, то компилятор будет размещать данные на стеке(возможно и в Java, но большими усилиями). <br>Задолго до появления Go существовали RTOS на основе Oberon, который тоже использует сборщик мусора, но не обязует пользоваться динамической памятью - Xoberon, Jbed. Правда, Oberon гораздо лучше подходит для RTOS чем Go, но у последнего есть свои козыри.<br>В частности, начиная с Go 1.5 проведена серьёзная работа по уменьшению задержек сборщика мусора. <br>https://talks.golang.org/2015/go-gc.pdf<br>http://www.pvsm.ru/blog-kompanii-mail-ru-group/155798<br> https://www.solaris.opennet.ru/openforum/vsluhforumID3/108556.html#168 Thu, 28 Jul 2016 15:08:13 GMT &gt; Над чем иронизируем? Go как раз разрабатывался с целью замены связки С++, <br>&gt; Java, Python в Google.<br><br>Плюсы он, определенно, не заменит. Хотя-бы потому что там GC вырубить нельзя, насколько я помню. Это гарантирует веселые лаги в неудачном раскладе и все что связано с реальным временем идет лесом. Ну кроме случая когда мсье утонченные ценители и хотят изощренно подолбаться. Дропбокс помнится опять переписывает бэкэнд, теперь с go на Rust. Так, дескать, быстрее.<br><br>&gt; О PHP они не упоминали, так как вряд ли активно его используют. <br>&gt; При этом сам Go легче каждого по отдельности.<br><br>У Go сборщик мусора с ножом к горлу, что ставит его в один ряд с лагучей явой. Он не такой монструозный, а в тормозной вебне лаги никто не заметит все-равно. Но как только захочется чего-то сверх того - GC та еще скотина. Реально Go имхо наподдаст яве и питону, потому что не такой монстр как ява и не такой тормоз как питон. Ну и с HTTP дружит явно лучше этих двух.<br><br>&gt; Кто Вам такое сказал?<br><br>Наблюдение за их активностью - пускают https://www.solaris.opennet.ru/openforum/vsluhforumID3/108556.html#167 Thu, 28 Jul 2016 14:25:54 GMT &gt; Чтобы уметь предусматривать - надо понимать как системы атакуют и какие техники <br>&gt; при этом используются. Защита от сферических угроз в вакууме неэффективна.<br><br>Странная логика.<br>Если Вы знаете как системы атакуют - то они должны быть защищены от этого по умолчанию. Но на этом нельзя останавливаться. Не думаете же Вы, что злоумышленники удовлетворятся неудачной попыткой, и не станут разрабытвать новые средства? Они как раз и заняты превращением сферических угроз в вакууме в действительно используемые. Вот тут недавно исследователи испытали сферичечкую угрозу - пакеты в репозиториях языков разработки с опечатками в названиях известных библиотек. Результаты - прекрасные. Я так понимаю, по Вашему, так делать не стоило и нужно было ждать, когда этим станут массово пользоваться злоумышленники, и только затем предпринимать какие-то действия?<br><br>&gt; Ты будешь строить бункер с пятиметровыми стенами. Хакер на это посмотрит, обнаружит <br>&gt; что крышу посторить забыли и уссываясь закинет туда кирпич. <br><br>Опять что-то с лог https://www.solaris.opennet.ru/openforum/vsluhforumID3/108556.html#166 Thu, 28 Jul 2016 14:04:37 GMT &gt; Си не так уж сложно использовать безопасно. Там больше роялят методики разработки <br>&gt; и общая паранойя разработчиков. <br><br>Почему Вы не включаете в методики разработки язык программирования? Это его важная часть.<br><br>&gt; Если этого нет - хренли толку с яп, разработчики все-равно накосячат.<br><br>Всё время повторяю одно и то же, разница есть в количестве ошибок, пропущенных автоматическими средствами. Если Вы не верите в эту разницу, попробуйте программировать всё в машинных кодах, а "хренли толку с яп, разработчики все-равно накосячат"(С). Или по вашему Си - это вершина программистской мысли и дальнейшее совершенствование средств разработки бесмысленно?<br><br>&gt; Образцовый пример - самолет у которого на <br>&gt; полпути кончилось горючее. Потому что перепутали метрические и имперские единицы. Так <br><br>Насколько я понимаю - в Ада есть возможность учесть единицы измерения, но никто не может заставить это использовать.<br><br>&gt; Видишь, оказывается даже на хваленой тобой Ada можно повесить фатальный баг<br><br>Я об этом случае знал задолго https://www.solaris.opennet.ru/openforum/vsluhforumID3/108556.html#165 Thu, 28 Jul 2016 13:25:27 GMT &gt; Прикольно наверное - изучить полдюжины ЯП, не зная нормально ни один из них в результате<br><br>Над чем иронизируем? Go как раз разрабатывался с целью замены связки С++, Java, Python в Google. О PHP они не упоминали, так как вряд ли активно его используют. При этом сам Go легче каждого по отдельности.<br><br>&gt; А почему пользователи rust не могут использовать сишные библиотеки без каких-то граблей?<br><br>Кто Вам такое сказал?<br><br>&gt; И занимаются каким-то анонизмом типа переписывания zlib<br><br>Откуда Вам знать, кто зачем что делает? Может развлекаются люди, а может и решают какой-нибудь практический вопрос. Обычным людям что с того?<br><br>&gt; В результате они изучают очередной ЯП на том же уровне понимания что и пых, <br>&gt; но верят что новая серебряная пуля еще убийственнее старой<br><br>а чуть позже пишите<br>&gt; Ну так динамическая типизация и скорость работы убивает, т.к. надо делать <br>&gt; много лишних проверок<br><br>Вам не кажется, что Вы себе противоречите?<br> https://www.solaris.opennet.ru/openforum/vsluhforumID3/108556.html#164 Thu, 28 Jul 2016 04:35:14 GMT Ну и где теперь MS, а где IBM и AS/400? А financial systems скоро будут одним сплошным блокчейном. Там требования к надежеости сильно ниже - блокчейн априори реплпцирован на всех. Вы с вашими финансовыми системами всего лишь горстка ископаемых из прошлого тысячелетия.<br> https://www.solaris.opennet.ru/openforum/vsluhforumID3/108556.html#163 Thu, 28 Jul 2016 04:31:58 GMT &gt; AS400 себе детали сама заказывала на замену.<br><br>Нашел чем удивить. Скоро холодильники будут сами закавыать продукты.<br>