форумы  помощь  поиск  регистрация  вход/выход  слежка

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

"Серия уязвимостей в ядре OpenBSD"	+/–
Сообщение от opennews on 15-Июл-16, 10:52
Разработчики системы  Triforce (https://www.nccgroup.trust/uk/about-us/newsroom-and-events/b.../), созданной для fuzzing-тестировния системных вызовов ядра Linux, адаптировали свой инструмент для других систем и провели проверку ядра OpenBSD. В результате проверки  в ядре OpenBSD было выявлено (http://openwall.com/lists/oss-security/2016/07/14/5) пять уязвимостей, которые могут использоваться для инициирования отказа в обслуживании через вызов краха ядра после определённых манипуляций со стороны непривилегированного пользователя. Ещё две проблемы могут эксплуатироваться пользователями, которым предоставлено право монтирования накопителей. Проблемы присутствуют в системных вызовах  mmap, kevent, __thrsleep, __thrsigdivert и  getdents, а также в реализации файловой системы tmpfs и коде отмонтирования ФС. Для всех уязвимостей подготовлены (http://seclists.org/oss-sec/2016/q3/68) рабочие прототипы эксплоитов. Анализ наличия других векторов атаки, способных привести к выполнению кода на уровне ядра, для данных уязвимстей  не проводился. Проблемы уже оперативно устранены (http://www.openbsd.org/errata59.html) в кодовой базе OpenBSD. URL: http://openwall.com/lists/oss-security/2016/07/14/5 Новость: http://www.opennet.dev/opennews/art.shtml?num=44790
Ответить | Правка | Cообщить модератору

Сообщения по теме

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

1. "Серия уязвимостей в ядре OpenBSD"	+10 +/–
Сообщение от Продавец_кирпичиков on 15-Июл-16, 10:52
Так как дырки не ремотные, Тео в надписи ничего не поменяет, и все будет по прежнему
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	19. "Серия уязвимостей в ядре OpenBSD"	+11 +/–
	Сообщение от Аноним (??) on 15-Июл-16, 15:52
	Попался как-то неуловимый Джо дворовым гопам. Гопы были не в курсе, поэтому у Джо появились 5 синяков и оторванный воротник.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	30. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Аноним (??) on 15-Июл-16, 16:19
	> Попался как-то неуловимый Джо дворовым гопам. Гопы были не в курсе, поэтому у Джо появились 5 синяков и оторванный воротник. Учитывая распространенность опенка в нашем мире, такой исход маловероятен.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	54. "Серия уязвимостей в ядре OpenBSD"	+1 +/–
	Сообщение от Stellarwind on 15-Июл-16, 17:03
	Судя по новости там в большинстве случаев валилось на assert-ах, но крах ядра конечно плохо в любом случае.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	68. "Серия уязвимостей в ядре OpenBSD"	–3 +/–
	Сообщение от Дегенератор on 15-Июл-16, 18:20
	Обновление с 5.4 на 5.5. Там они сменили формат времени, порекомендовали все удалить и отключить. Решил испытать судьбу на удаленной. Залил 5.5 сорцы. Обновил бинутилс, обновил ядро, думаю остальное после ребута, если че не так, ну пропустится. В итоге кернел паника. "Неубиваемая".
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	81. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Zarat (ok) on 16-Июл-16, 00:49
	Только дегенерат может считать OpenBSD "неубиваемой" (или по другому надежной) ОС. Если б этот школьник читал маны, то понял бы, OpenBSD разрабатывается как безопасная, и в плане надежности проигрывает например Линуксу. Философия Линукс - получить пробоину, но выстоять и позволить злоумышленнику зашифровать файлы и требовать выкуп, философия OpenBSD - получить пробоину и упасть на assert. В итоге получаем безопасность в ущерб надежности.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	92. "Серия уязвимостей в ядре OpenBSD"	–3 +/–
	Сообщение от Дегенератор on 16-Июл-16, 09:19
	Разве ненадежная система может быть безопасной? Толку то с того что ты манов перечитался.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	97. "Серия уязвимостей в ядре OpenBSD"	+2 +/–
	Сообщение от Goose on 16-Июл-16, 12:54
	Устойчивость и безопасность - это разные параметры.
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	124. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от КО on 18-Июл-16, 08:51
	>Разве ненадежная система может быть безопасной? Так это, безопасный [:25 буква глаголицы:] это тот, который не встает, а не тот, который не падает. :)
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	142. "Серия уязвимостей в ядре OpenBSD"	–1 +/–
	Сообщение от Аноним (??) on 20-Июл-16, 00:38
	> Обновление с 5.4 на 5.5. Там они сменили формат времени, порекомендовали все > удалить и отключить. Решил испытать судьбу на удаленной. Залил 5.5 сорцы. > Обновил бинутилс, обновил ядро, думаю остальное после ребута, если че не > так, ну пропустится. В итоге кернел паника. "Неубиваемая". Лишите Linux (работоспособного) /sbin/init так же, как вы это сделали с опёнком, или же убейте smss.exe в винде, и получите то же самое.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	157. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Аноним (??) on 28-Июл-16, 05:34
	В линуксах ориентированных на практические применения несколько менее стремные технологии обновления init и системных библиотек.
	Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

	74. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от anonymous (??) on 15-Июл-16, 20:52
	>крах ядра конечно плохо в любом случае Пока сервер ребутится, можно провернуть ip spoofing и провести атаку на другой хост
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	87. "Серия уязвимостей в ядре OpenBSD"	+2 +/–
	Сообщение от Аноним (??) on 16-Июл-16, 03:00
	> Пока сервер ребутится, можно провернуть ip spoofing и провести атаку на другой хост Если атакующий может спуфить айпи в локалке, ему уже все-равно - запущен там сервер или нет. Если он может проворачивать такой спуф то и окончательно обдурить свичи сможет.
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

4. "Серия уязвимостей в ядре OpenBSD"	+19 +/–
Сообщение от Аноним (??) on 15-Июл-16, 11:31
Openbsd - это сама сесюрность! Она не уязвима. Не перед чем! Никогда.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	6. "Серия уязвимостей в ядре OpenBSD"	–23 +/–
	Сообщение от Comdiv (ok) on 15-Июл-16, 11:45
	Сам по себе выбор языка Си для создания ОС уже говорит достаточно об отношеннии к безопасности.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	7. "Серия уязвимостей в ядре OpenBSD"	–9 +/–
	Сообщение от arisu (ok) on 15-Июл-16, 11:49
	дебилу типа тебя завсегда что‐нибудь мешает. то штаны, то язык…
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	21. "Серия уязвимостей в ядре OpenBSD"	+5 +/–
	Сообщение от Аноним (??) on 15-Июл-16, 16:06
	> завсегда что‐нибудь мешает. то штаны, то язык… Подожди, мы ему по секрету шепнем что фирмвари ABS и подушек безопасности в автомобилях - на сях пишут. Пусть теперь ходит пешком.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	25. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Аноним (??) on 15-Июл-16, 16:14
	>> завсегда что‐нибудь мешает. то штаны, то язык… > Подожди, мы ему по секрету шепнем что фирмвари ABS и подушек безопасности > в автомобилях - на сях пишут. Пусть теперь ходит пешком. С одиннадцатью тысячами глобальных переменных. Кстати, вспоминается недавняя новость, как автопилот теслы укоротил водителя на голову, потому что не увидел впереди фуру.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	55. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от АнонимХ (ok) on 15-Июл-16, 17:05
	Так водитель ее тоже не увидел. В яркий солнечный день, при контровом свете. Так что не считается. А то попадание метеорита на теслу можно будет списать, чего уж там
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	61. "Серия уязвимостей в ядре OpenBSD"	–3 +/–
	Сообщение от Аноним (??) on 15-Июл-16, 17:42
	> Так водитель ее тоже не увидел. В яркий солнечный день, при контровом > свете. Так что не считается. А то попадание метеорита на теслу > можно будет списать, чего уж там Это лично Маск продолбался - он должен был заложить в конструкцию противометеоритный радар и средства уклонения и уничтожения. Как вам идея купить автомобиль по цене МКС?
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	71. "Серия уязвимостей в ядре OpenBSD"	+2 +/–
	Сообщение от mario (??) on 15-Июл-16, 20:11
	Так водила Гарри Поттера смотрел в это время.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	60. "Серия уязвимостей в ядре OpenBSD"	+1 +/–
	Сообщение от Аноним (??) on 15-Июл-16, 17:37
	> С одиннадцатью тысячами глобальных переменных. Как там rust'о'маны справляются с 11К глобальных переменных - это мы еще будем посмотреть. > Кстати, вспоминается недавняя новость, как автопилот теслы укоротил водителя на голову, > потому что не увидел впереди фуру. На чем этот автопилот написан - я вообще не в курсе. А фирмварь антиблокировочной системы, электронный газ и прочее управление мотором - скорее всего на си. В случае особо сильных требований может быть диалект типа MISRA C, который может реализовываться как компилятором так и проверкой сорца внешней программой. Кто именно завернет билд - не принципиально.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	80. "Серия уязвимостей в ядре OpenBSD"	–2 +/–
	Сообщение от Comdiv (ok) on 16-Июл-16, 00:06
	> типа MISRA C, который может реализовываться как компилятором так и проверкой > сорца внешней программой. Кто именно завернет билд - не принципиально. Далеко не все ограничения MISRA C могут быть проверены автоматически, но тут главное другое - MISRA, фактически, предоставляет другой язык, пусть и совместимый с Си. Также, это свидетельствует о признании проблемы со стороны промышленности. И тут интересен подход: - Выпустить нечто мало пригодное для надёжного прогаммирования. - Начать применять его для критичных к корректности задач. - Получить кучу проблем, и объявить половину возможностей небезопасными. - Выпустить об этом документ и начать продавать его за деньги. - Выпустить утилиту для проверки на соответствие документу и начать продавать его за деньги - Всё равно иметь кучу проблем, но продолжать использовать.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	126. "Серия уязвимостей в ядре OpenBSD"	+2 +/–
	Сообщение от Аноним (??) on 18-Июл-16, 20:00
	> Далеко не все ограничения MISRA C могут быть проверены автоматически, Более того, согласно Тюрингу нельзя даже определить - повиснет программа или нет. Есть интересные способы прострела пяток. Например, можно обслуживать аппаратный вачдог в прерывании таймера. Заметь, я ничего не сказал про ЯП. Так тупануть можно на любом ЯП позволяющем системное прогрмамирование МК. > главное другое - MISRA, фактически, предоставляет другой язык, Язык тот же самый - Си. С джентльменскими договоренностями про dos и donts нацеленными на уменьшение классов ошибок. Писать без ошибок можно и на полной версии, DJB проверял. Так навскидку. Возьмем tweetnacl. Достаточно маленький чтобы прочитать и достаточно большой чтобы делать что-то полезное человечеству. Вот где он может облажаться? Память не выделяет, опасных операций не делает, внешних зависимостей одна штука - получение извне рандома. А вот какие-то там хипстерские рантаймы делающие непонятно что - всегда подкинут свинью. Сколько человек на планете вообще разбирается - будет ли вон та операция в rust константой по времени, например? А для криптографии это важно - зарубает целый класс атак, делающих выводы по разному времени выполнения. Такие вещи могут быть абсолютно фатальны. Скажем достаточно необдуманно сравнивать пароль чем-то типа memcmp и далее можно просто глядя на дельту по времени угадывать его по отдельным буквам. И сложность подбора пароля из 10 символом станет не 256^10 а 256 * 10, что как-то совсем не айс. На сях подобные вещи делать сравнительно просто, потому что язык достаточно простой и рантайм опционален и не пытается втиснуться вообще везде, типа чистой математики. > с Си. Также, это свидетельствует о признании проблемы со стороны промышленности. Разработка софта вообще очень проблемная отрасль. У прогрмамистов есть такой анекдот: если программа с первого раза заработала правильна - вырубай скорее и ищи ошибку. > - Выпустить нечто мало пригодное для надёжного прогаммирования. Guns don't kill people. Языки прогрмамирования не делают ошибок, ошибки делают люди. Ты чего хочешь? Заменить дорогих элитных сишников, понимающих что они делают на хипстерских обезьянок дешевле? Чудес не бывает, обезьянки не будут понимать как это работает, сложный рантайм все усугубит. Тех кто будет реально понимать что, как и почему работает будут считанные единицы на планету, будет множество неочевидных failure modes. Результат не заставит себя ждать. Посмотри вокруг. В этих php, python, ruby и прочих вообще нет работы с указателями. Но это не мешает хакерам взламывать большинство серверов через дырявую вебню. А просто потому что вебмартышки уверены что за них рантайм подумает. Иногда это так, но Боби Тэйблс и его друзья готовы с этим тезисом поспорить. Достаточно успешно, кста. > - Начать применять его для критичных к корректности задач. Люди применяют для задач инструменты которые работают. Си используется в критичных задачах десятилетиями и работает это получше других инструментов. Системное программирование вообще к надежности требвательно выше среднего. В ядре системы одна ошибка - и ты идешь перезагружать систему. Хороший стимул не лажать в коде. > - Получить кучу проблем, и объявить половину возможностей небезопасными. Системное програмирование подразумевает возможность прострелить себе пятку. Разумеется это не безопасно. Жить вообще вредно - от этого умирают. > - Выпустить об этом документ и начать продавать его за деньги. > - Выпустить утилиту для проверки на соответствие документу и начать продавать его за деньги Требования достаточно общеизвестны, утилит более одной. На том же ядре Linux например гоняют с дюжину разных анализаторов периодически. И живые люди код читают. Но все-равно иногда пролезают ошибки. Кода много, не все взаимодействия между разными частями - тривиальные. И никакой ЯП не спасет тебя от этого сам по себе. > - Всё равно иметь кучу проблем, но продолжать использовать. А еще можно верить в серебряные пули, нанимать долбоклюев ничего не смыслящих в безопасности и при этом в силу глупости надеяться что врожденный кретинизм програмера лечится заменой ЯП, а не заменой програмера. Только как там в басне говорится: вы друзья, как ни садитесь...
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	127. "Серия уязвимостей в ядре OpenBSD"	–1 +/–
	Сообщение от Comdiv (ok) on 18-Июл-16, 23:20
	> в rust константой по времени, например? А для криптографии это важно > - зарубает целый класс атак, делающих выводы по разному времени выполнения. > Такие вещи могут быть абсолютно фатальны. Скажем достаточно необдуманно сравнивать пароль > чем-то типа memcmp и далее можно просто глядя на дельту по > времени угадывать его по отдельным буквам. Тут Rust не лучше и не хуже C. И в C рантайм не копеечный, и в Rust не жирный, и оба позволяют работать без рантайма. > Guns don't kill people. Языки прогрмамирования не делают ошибок, ошибки делают люди. Тем не менее, количество инцидентов с оружием больше там, где к нему свободный доступ. > Ты чего хочешь? Заменить дорогих элитных сишников, понимающих что они делают > на хипстерских обезьянок дешевле? Чтобы их заменить, они должны быть в достаточном количестве. Их банально не хватает. Если есть высококлассный специалист, лучшее, что можно сделать - это позволить ему работать на том, на чём он хочет и знает. > Чудес не бывает, обезьянки не будут понимать > как это работает, сложный рантайм все усугубит. Далеко не все языки, являющиеся более ошибкоустойчивыми чем C, требуют жирного рантайма. Та же Modula-2. Тут сама постановка вопроса удивляет, что если программист профессионал, то ему не нужна подстраховка. Вот Дреппер же профессионал? А сколько уязвимостей нашли в glibc? >  В этих php, python, ruby и прочих вообще нет работы > с указателями. Но это не мешает хакерам взламывать большинство серверов через > дырявую вебню. Вы назвали ужасные, с моей точки зрения, языки. Точнее, как скриптовые они может быть и неплохи, то есть для такого кода, который не надо никому показывать, но для построения крупных проектов динамическая типизация - это болото. Поэтому в ФСБуке и делают свой транслятор для PHP-образноко языка со статической типизацией. > Люди применяют для задач инструменты которые работают. Си используется в критичных > задачах  десятилетиями и работает это получше других инструментов. Лучше языка Ada, массово применяемого в авиастроении? Очень критичная область, надо сказать. > Системное программирование > вообще к надежности требвательно выше среднего. В ядре системы одна ошибка > - и ты идешь перезагружать систему. Хороший стимул не лажать в коде. Тут, как раз, архитектура и язык могут решать. QNX характерна устойчивостью к падению за счёт микроядерной архитектуры. В архаичной Oberon вся ОС вместе с программами выполнялась в едином адресном пространстве, но за счёт языка с герметичными типами была устойчива, хотя при желании и можно было запороть память псевдомодулем SYSTEM. > Но все-равно иногда пролезают ошибки. Кода много, не все взаимодействия между > разными частями - тривиальные. И никакой ЯП не спасет тебя от > этого сам по себе. > А еще можно верить в серебряные пули, нанимать долбоклюев ничего не смыслящих > в безопасности и при этом в силу глупости надеяться что врожденный > кретинизм програмера лечится заменой ЯП, а не заменой програмера. Только как > там в басне говорится: вы друзья, как ни садитесь... Речь идёт лишь о том, чтобы исключить проблемы, решаемые языком. О серебряной пуле никто не мечтает, но упрощение жизни - возможно. Не нужно кидаться крайностями, и представлять людей глупцами из-за их желания воспользоваться плодами прогресса.
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	136. "Серия уязвимостей в ядре OpenBSD"	+1 +/–
	Сообщение от Аноним (??) on 19-Июл-16, 03:55
	> Тут Rust не лучше и не хуже C. Си достаточно простой и потому предсказуемый. Его легко обрубить до минимально необходимого core когда никто не будет умничать в месте где это смерти подобно. Это фича. > И в C рантайм не копеечный, В си рантайм будет такой какой я скажу. Может быть хоть нулевого размера. Фирмвари микроконтроллеров, бутлоадеров и ядра ОС так и пишут. А фирмвари микроконтроллеров бывают очень требовательными к надежности. То что rust'o'man-ы могут лучше - делом докажите. > и в Rust не жирный, и оба позволяют работать без рантайма. С чем я его и поздравляю, но громкие слоганы о том что на си нельзя писать безопасно не соответствуют действительности. > Тем не менее, количество инцидентов с оружием больше там, где к нему свободный доступ. Почему-то статистика это не подтверждает. Недавно попадалось утверждение что крупных killing spree в США и России было одинаково за последний год. А в штатах массовые убийства обычно случаются в зонах свободных от оружия почему-то. > Чтобы их заменить, они должны быть в достаточном количестве. Их банально не хватает. Чудес не бывает: как заплачено так и захреначено. Предлагайте конкурентоспособные зарплаты или наслаждайтесь мартышками. > Если есть высококлассный специалист, лучшее, что можно сделать - это > позволить ему работать на том, на чём он хочет и знает. А если специалист низкоквалифицированный, он будет сажать глупые баги на любом ЯП. Потому что низкоквалифицированный. Что хуже - такие кадры часто мнят себя супер-про, ворочая огромными рантаймами и фреймфорками. Получается обезьяна с гранатой. > Та же Modula-2. Ну и где эта Modula-2? Фирмвари на си в ответственных применениях - вижу. Modula-2 не вижу. Никак и нигде. > Тут сама постановка вопроса удивляет, что если программист профессионал, то ему не > нужна подстраховка. Вот Дреппер же профессионал? А сколько уязвимостей нашли в glibc? Во первых, Дреппер далеко не единственный автор кода. Во вторых, даже Дреппер иногда может ошибаться. В третьих Дреппер зазнался в край, что не способствует отсутствию ошибок и работе над ними. Но это все фигня. Основная проблема glibc - то что в погоне за фичами и производительностью glibc стал весьма жирным. А в большой программе и багов заведомо много. > Вы назвали ужасные, с моей точки зрения, языки. Однако в эксплуатируемых уязвимостей в самих языках не так уж много. А вот глупых логических ошибок в паршивом коде - более чем. Кто system() вызывает с пользовательскими данными, кто файлы пишет черти-как, не зная что пользователь может воткнуть в имя файла что угодно, даже "../../etc/passwd". Некоторые переклинены на текст-ориентированных ЯП, поэтому подолбать их неправильным эскейпингом и далее всучить им странную строку делающую совсем не то что они думали - милое дело. А вон DHCP сервера красиво рутали linux за счет isc dhcp клиента в паре с bash. > Точнее, как скриптовые они может быть и неплохи, то есть для такого кода, который не > надо никому показывать, но для построения крупных проектов динамическая типизация - это болото. Это реально минное поле. Можно спокойно приравнять бананы к гвоздям, никто ничего не скажет. JS из той же области. Очень бесит. Си в этом плане близок к оптимуму. По дефолту обругает но если я очень хочу считать бананы гвоздями - можно заэнфорсить явно. Те кто так делает должны разумеется понимать - нафига. Паскаль какой-нибудь в этом плане сильно противнее - убедить его что бананы это гвозди можно только при помощи трехэтажных костылищ. В конце концов бананы все-равно пойдут под видом гвоздей, если уж это надо, но долбаться придется больше и ЯП начинает активно мешаться. > Поэтому в ФСБуке и делают свой транслятор для PHP-образноко языка со статической типизацией. У них еще и субсет урезанный и даже предкомпилируемый IIRC. Они пилят большой проект и огребают сполна все прелести. И по части производительности и по возможности это поддерживать. Но на си написаны монстрики типа линуксного ядра. Там кода побольше чем в любом фэусбуке. А оно еще и как-то работает. > Лучше языка Ada, массово применяемого в авиастроении? Очень критичная область, надо сказать. Сказать что Ada массово применяется - покривить душой. А так то NASA делало еще более забористый язык, где описываются допустимые переходы между состояниями объектов. И все это круто и замечательно, только у NASA релизы редкие, финансирование условно-анлимное, задача более-менее ясна сразу на старте. Поэтому они могут попыхтеть и нормально притянуть архитектуру к формальному описанию. А какой-нибудь Элон Маск - юзает обычный Linux и даже компоненты не rad-hard. А надежноть добивает многократным резервированием, т.к. это ширпотреб - можно поставить много и выехать на этом. И ничего, летает. Что у него только не фэйлило, но это в основном механика и просто не отлаженные экспериментальные технологии. А бортовые компьютеры по крупному вроде ни разу не отказывали. > Тут, как раз, архитектура и язык могут решать. А могут и не решать. А иногда можно сделать ход конем и из кучи ненадежных систем можно сделать надежную мета-систему. Просто крутанув теорвер в свою пользу. Этим развлекаются и Маск, и Гугл и кто там еще. Основной плюс - это дешево и использует уже готовые решения, не требуя сверх-затратных вещей. Которые может и круто и здорово, но даже NASA напрягается и могло позволить себе такой шик только к лунной гонке, когда их финансировали анлимно. > QNX характерна устойчивостью к падению за счёт микроядерной архитектуры. И все бы замечательно, но у меня и прозаичный Linux не падает. Год аптайма в эмбедовке он точно делает. Больше - иногда таки софт обновляют. Или просто пропадает питание. Ну и что там даст переписывание на микроядра, даже на аде? Много гемора с результатом близким к нулю? > с герметичными типами была устойчива, хотя при желании и можно было > запороть память псевдомодулем SYSTEM. А сейчас, понимаешь ли, периферия - это участок памяти. Потому что это круто, просто, быстро и можно разгрузить DMA. Кстати одно неверное программирование DMA - и железка прострелит череп системе. Софт это даже перехватить никак не может. Железо научилось перехватывать это относительно недавно (iommu). Вообще, современное железо настолько сложное и хрупкое что все эти извраты с супернадежностью на нем себя не оправдают. Супер-ЯП может посыпаться на какой-нибудь errata железа. А линуксное ядро с его сями эту errata три раза прокостылило, собрало feedback и проверило фикс годами работы без сбоев. Так и живем. Железо сейчас ни разу не лучше софта. > Речь идёт лишь о том, чтобы исключить проблемы, решаемые языком. Звучит как план по отливке серебряных пуль. В том плане что упомянутый язык создает не так уж много проблем и они достаточно известные а профит в лучшем случае весьма маргинальный. А сватаемая муета к тому же не совместима с существующим софтом (простите, а на rust можно написать либу? А чтобы потом еще и прикрутить ее к другим ЯПам, как сишную? А сишную либу к rust?). Там вроде с этим тот еще факап. А планы резко переписать все на Rust - форменное донкихотство. Извини, с 1989 года на том же си понаписали много чего и отказываться от этого никто не будет. Желающие могут переписать на этом хотя-бы Linux или как там это будет называться для начала. Для понимания масштаба работ, если на совместимость таки будет решено положить. > пуле никто не мечтает, но упрощение жизни - возможно. Не нужно кидаться крайностями, Чтобы не кидаться в крайности должен быть нормальный интероп с существующим софтом. Rust в этом чем таким вообще похвастает?
	Ответить | Правка | ^ к родителю #127 | Наверх | Cообщить модератору

	141. "Серия уязвимостей в ядре OpenBSD"	–1 +/–
	Сообщение от Comdiv (ok) on 19-Июл-16, 15:43
	> То что rust'o'man-ы могут лучше - делом докажите. Не знаю, кого Вы имеете ввиду. Мне Rust не нравится. > но громкие слоганы о том что на си нельзя писать > безопасно не соответствуют действительности. Почему нельзя? Можно, но при прочих равных - дороже. >> Тем не менее, количество инцидентов с оружием больше там, где к нему свободный доступ. > Почему-то статистика это не подтверждает. Просто надо сравнивать сравнимое. Например, Украину три года назад и сейчас, когда оружие стало более доступно(не разрешено, а только более доступно). Одна и та же страна, одни и те же люди, единственная, важная в данном аспекте, разница - доступность оружия. > А если специалист низкоквалифицированный, он будет сажать глупые баги на любом ЯП. Ошибки ошибкам рознь. Типичный сценарий в игроделе: программисты пишут движок, дизайнеры уровней пишут скрипты. Не смотря на то, что код дизайнеров может быть ужасен, игра казывается годной. Специалист в своей области может быть неважным программистом, но при правильном подходе его код может быть пригоден без необходимости приписки при нём кодировщика. > Ну и где эта Modula-2? Летает в космосе, в том числе. Да и не понятно, зачем ориентироваться на популярность? Вон, в NASA сделали предметно ориентированный язык для управления марсоходом. Какая разница, что это штучное применение? Главное, что он выполняет свою задачу лучше, чем не подходящий для этого язык. > Но на си написаны монстрики типа линуксного ядра. Там кода побольше чем > в любом фэусбуке. А оно еще и как-то работает. По разным оценкам в ядро вбуханы миллиарды. Это цена больших усилий. >> Лучше языка Ada, массово применяемого в авиастроении? Очень критичная область, надо сказать. > только у NASA релизы редкие, финансирование условно-анлимное, > задача более-менее ясна сразу на старте. Поэтому > они могут попыхтеть и нормально притянуть архитектуру к формальному описанию. Речь идёт о коммерческом авиастроении, в которой денежку считают бережно. Так что всё наоборот- используют Ada не потому что денего сколько угодно, а потому что их ограниченное количество. > А какой-нибудь Элон Маск - юзает обычный Linux и даже компоненты не > rad-hard. Надо  будет познакомится с этим подробнее >> Тут, как раз, архитектура и язык могут решать. > А могут и не решать. А иногда можно сделать ход конем и Дело в том, что ход конём не отменяет необходимости в выборе правильной архитектуры и языка. И, кстати, это тоже можно считать признаком высококлассного специалиста, способного выбирать лучшие решения без привязки к любимым игрушкам. >> QNX характерна устойчивостью к падению за счёт микроядерной архитектуры. > И все бы замечательно, но у меня и прозаичный Linux не падает. Здорово, но с устойчивостью QNX, он всё равно не сравнится, даже если к Вам это и удаётся за счёт личного мастерства. Вы сами писали, одна ошибка - уходишь в перезагрузку. И опять таки, надо учитывать, что в "прозаичный" Linux вбуханы большие деньги, скорее всего, куда большие, чем в QNX. > переписывание на микроядра, даже на аде? Много гемора с результатом близким > к нулю? Переписывать уже отлаженный код бесмыссленно. Деньги уже потрачены и их не вернуть. Но для написания нового кода не обязательно идти по старым граблям. > современное железо настолько сложное и хрупкое что все эти извраты с > супернадежностью на нем себя не оправдают. Это, кстати, тоже серьёзная проблема, но всё же другая история. И костыли для железа на надёжных языках пишутся не хуже, чем на Си. Тут они в равной позиции. > А сватаемая муета к > тому же не совместима с существующим софтом (простите, а на rust > можно написать либу? А чтобы потом еще и прикрутить ее к > другим ЯПам, как сишную? А сишную либу к rust?) Мне самому не нравится Rust и желания писать на нём нет, но насколько можно судить из документации, всё это возможно и сделано довольно удобно. > А планы резко переписать все на > Rust - форменное донкихотство. А у кого есть такие планы? Старое остаётся на Си, новое пишется на чём-то получше, что больше всего подходит. Те разработчики, что ничего знать не хотят, кроме любимого Си, пишут на Си. Все счастливы и делают свою полезную работу. > Желающие могут переписать на этом хотя-бы Linux или как там это Вообще не вижу смысла повторять Linux, если уж стоит задача создавать ОС с нуля > Для понимания масштаба работ С кучей вбуханых денег конкурировать сложно. > Чтобы не кидаться в крайности должен быть нормальный интероп с существующим софтом. > Rust в этом чем таким вообще похвастает? Да, разработчики это учли.
	Ответить | Правка | ^ к родителю #136 | Наверх | Cообщить модератору

	134. "Серия уязвимостей в ядре OpenBSD"	–1 +/–
	Сообщение от Comdiv (ok) on 19-Июл-16, 01:45
	> вокруг. В этих php, python, ruby и прочих вообще нет работы > с указателями. Но это не мешает хакерам взламывать большинство серверов через Забыл упомянуть, что когда PHP не справляется с созданием уязвимостей собственными силами, ему на помощь может прийти Си http://www.linux.org.ru/news/security/4057482/page1 Да и указатели в этих языках есть. Нет арифметики уазателей и синтаксически они не выделены.
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	137. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Аноним (??) on 19-Июл-16, 05:12
	> Забыл упомянуть, что когда PHP не справляется с созданием уязвимостей собственными силами, > ему на помощь может прийти Си Действительно, ну не rust же. На rust вообще либы которые к пыху подключить можно - бывают? Рассуждения о том что все должны выбросить пых и писать на rust идут лесом по очевидной причине. Пых делает свое дело, выплюнуть хтмлку на нем чуть ли не пара строк, на нем написана куча вебни и никто не подорвется ее переписывать, потому что она уже есть и работает и бухать сотни денег и времени ради маргинального результата никто в здравом уме не будет.
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	139. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Comdiv (ok) on 19-Июл-16, 14:11
	> Действительно, ну не rust же. На rust вообще либы, > которые к пыху подключить можно - бывают? На Rust можно писать обычные библиотеки, так что и к PHP его можно приладить. Впрочем, зачем лепить вместе Rust и PHP, если можно использовать более подходящий для этого Go. > Рассуждения о том что все должны выбросить > пых и писать на rust идут лесом по очевидной причине. А где Вы видели такие рассуждения? Не нужно переписывать старое, но и при написании нового не стоит залезать в старые грабли. Но есть и те, кто, накушавшись "Пых делает свое дело", таки стремяться выкинуть и переписать. Пример тому - ФСБук, пилящий статически типизированный PHP-подобный язык Hack ради повышения надёжности и скорости.
	Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

	158. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Аноним (??) on 28-Июл-16, 06:00
	> Впрочем, зачем лепить вместе Rust и PHP, если можно использовать более подходящий > для этого Go. Прикольно наверное - изучить полдюжины ЯП, не зная нормально ни один из них в результате. В то что каждый первый может быть гением и полиглотом я пожалуй не поверю. > А где Вы видели такие рассуждения? Не нужно переписывать старое, но и > при написании нового не стоит залезать в старые грабли. А почему rust'о'маны не могут использовать сишные библиотеки без каких-то граблей? И занимаются каким-то анонизмом типа переписывания zlib, при том что к изначальному проекту это не имеет никакого отношения, зато надолго вклинило проект, а насколько их таких там хватит это потом майнтайнить - большой вопрос. Одно дело лихо переписать здесь и сейчас и совсем другое - майнтайнить 10 лет. > Но есть и те, кто, накушавшись "Пых делает свое дело", таки стремяться > выкинуть и переписать. В результате они изучают очередной ЯП на том же уровне понимания что и пых, но верят что новая серебряная пуля еще убийственнее старой. Мне почему-то кажется что это их ни от чего не спасет и как максимум они могут получить некоторое фалломорфирование классов багов, а вовсе не. > Пример тому - ФСБук, пилящий статически типизированный PHP-подобный > язык Hack ради повышения надёжности и скорости. Ну так динамическая типизация и скорость работы убивает, т.к. надо делать много лишних проверок не изменились ли типы, и позволяет наворачивать целые новые классы вкусных свежих багов, когда никто не скажет что огульное приравнивание бананов к гвоздям без выражения явного желания сделать именно это - выглядит подозрительно. По сути динамические ЯП рубают целую категорию статического анализа и получают то что получают. В больших проектах это неизбежно воздается.
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	165. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Comdiv (ok) on 28-Июл-16, 16:25
	> Прикольно наверное - изучить полдюжины ЯП, не зная нормально ни один из них в результате Над чем иронизируем? Go как раз разрабатывался с целью замены связки С++, Java, Python в Google. О PHP они не упоминали, так как вряд ли активно его используют. При этом сам Go легче каждого по отдельности. > А почему пользователи rust не могут использовать сишные библиотеки без каких-то граблей? Кто Вам такое сказал? > И занимаются каким-то анонизмом типа переписывания zlib Откуда Вам знать, кто зачем что делает? Может развлекаются люди, а может и решают какой-нибудь практический вопрос. Обычным людям что с того? > В результате они изучают очередной ЯП на том же уровне понимания что и пых, > но верят что новая серебряная пуля еще убийственнее старой а чуть позже пишите > Ну так динамическая типизация и скорость работы убивает, т.к. надо делать > много лишних проверок Вам не кажется, что Вы себе противоречите?
	Ответить | Правка | ^ к родителю #158 | Наверх | Cообщить модератору

	168. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Аноним (??) on 28-Июл-16, 18:08
	> Над чем иронизируем? Go как раз разрабатывался с целью замены связки С++, > Java, Python в Google. Плюсы он, определенно, не заменит. Хотя-бы потому что там GC вырубить нельзя, насколько я помню. Это гарантирует веселые лаги в неудачном раскладе и все что связано с реальным временем идет лесом. Ну кроме случая когда мсье утонченные ценители и хотят изощренно подолбаться. Дропбокс помнится опять переписывает бэкэнд, теперь с go на Rust. Так, дескать, быстрее. > О PHP они не упоминали, так как вряд ли активно его используют. > При этом сам Go легче каждого по отдельности. У Go сборщик мусора с ножом к горлу, что ставит его в один ряд с лагучей явой. Он не такой монструозный, а в тормозной вебне лаги никто не заметит все-равно. Но как только захочется чего-то сверх того - GC та еще скотина. Реально Go имхо наподдаст яве и питону, потому что не такой монстр как ява и не такой тормоз как питон. Ну и с HTTP дружит явно лучше этих двух. > Кто Вам такое сказал? Наблюдение за их активностью - пускают пар и переписывают уже существующие либы. Круто наверное - zlib какой-нибудь переписать. >> И занимаются каким-то анонизмом типа переписывания zlib > Откуда Вам знать, кто зачем что делает? Может развлекаются люди, а может > и решают какой-нибудь практический вопрос. Обычным людям что с того? Поскольку rust'о'маны занимаются таким онанизмом сплошь и рядом - я делаю вывод что с подключением сишных библ у них серьезные проблемы. Если это не так - тода вывод еще менее вкусный: большинство rust'o'манов просто форменные онанисты. > а чуть позже пишите >> Ну так динамическая типизация и скорость работы убивает, т.к. надо делать >> много лишних проверок > Вам не кажется, что Вы себе противоречите? Нет, не кажется. В чем именно тут противоречие и где? Хреново знать можно любой язык. И статически типизированный и динамически. И если кто-то бегает по языкам как вошь на сковородке, варинтов два: либо перед нами реально гений и Дональд Кнут нервно курит в сторонке, либо что вероятнее, перед нами какой-нибудь вебдев-бддлокодер. Знающий процентов по 5 от того и этого.
	Ответить | Правка | ^ к родителю #165 | Наверх | Cообщить модератору

	169. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Comdiv (ok) on 28-Июл-16, 22:17
	> Плюсы он, определенно, не заменит. Надо уточнить - для задач Google заменит. > Хотя-бы потому что там GC вырубить нельзя, > насколько я помню. Это гарантирует веселые лаги в неудачном раскладе и > все что связано с реальным временем идет лесом. Go был спроектирован лучше Java - если не безобразничать, то компилятор будет размещать данные на стеке(возможно и в Java, но большими усилиями). Задолго до появления Go существовали RTOS на основе Oberon, который тоже использует сборщик мусора, но не обязует пользоваться динамической памятью - Xoberon, Jbed. Правда, Oberon гораздо лучше подходит для RTOS чем Go, но у последнего есть свои козыри. В частности, начиная с Go 1.5 проведена серьёзная работа по уменьшению задержек сборщика мусора. https://talks.golang.org/2015/go-gc.pdf http://www.pvsm.ru/blog-kompanii-mail-ru-group/155798
	Ответить | Правка | ^ к родителю #168 | Наверх | Cообщить модератору

	101. "Серия уязвимостей в ядре OpenBSD"	+1 +/–
	Сообщение от продаватель_кирпичиков on 16-Июл-16, 15:23
	>> С одиннадцатью тысячами глобальных переменных. > Как там rust'о'маны справляются с 11К глобальных переменных - это мы еще > будем посмотреть. >> Кстати, вспоминается недавняя новость, как автопилот теслы укоротил водителя на голову, >> потому что не увидел впереди фуру. > На чем этот автопилот написан - я вообще не в курсе. А > фирмварь антиблокировочной системы, электронный газ и прочее управление мотором - скорее > всего на си. В случае особо сильных требований может быть диалект > типа MISRA C, который может реализовываться как компилятором так и проверкой > сорца внешней программой. Кто именно завернет билд - не принципиально. Специалист-автоэлектронщик детекдет :) можна поинтересоватся, где живет фирмварь ABS/ESR  на нормальной, ( а не прокатной, как тесла ) машине ?
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	79. "Серия уязвимостей в ядре OpenBSD"	–1 +/–
	Сообщение от Comdiv (ok) on 15-Июл-16, 23:52
	> Подожди, мы ему по секрету шепнем что фирмвари ABS и подушек безопасности > в автомобилях - на сях пишут. Пусть теперь ходит пешком. Это довольно смешно, но у меня нет автомобиля из принципиальных соображений. Но как ни странно, длинные расстояния я преодолеваю не пешком.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	130. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Аноним (??) on 18-Июл-16, 23:54
	Самолетами и поездами тоже не пользуешься? Далеко ходить не надо - загугли про московское метро и их реалтаймный линукс.
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	131. "Серия уязвимостей в ядре OpenBSD"	–1 +/–
	Сообщение от Comdiv (ok) on 19-Июл-16, 00:38
	На самолётах не летал. Впрочем, насколько мне известно, в этой отрасли предпочитают язык Ada, уж более цена ошибки высока для C. Да и в поездах многие используют https://www.seas.gwu.edu/~mfeldman/ada-project-summary.html#... И автомобиля у меня нет далеко не из-за C.
	Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

	138. "Серия уязвимостей в ядре OpenBSD"	+1 +/–
	Сообщение от Аноним (??) on 19-Июл-16, 06:47
	> На самолётах не летал. Впрочем, насколько мне известно, в этой отрасли предпочитают язык Ada, Ты вот прямо за всю начинку, от всех производителей расписываешься на чем они там это наворачивают? Можно поспорить что там навалом и сишных фирмварей в куче микроконтроллеров (коих напихано много и повсеместно). > уж более цена ошибки высока для C. Наверное именно поэтому куча сишных фирмварей рулит в микроконтроллерах всех мастей всевозможными процессами. Там применяют ряд методов чтобы ошибок было меньше. Только в управлюящих/реалтаймных процессах "высока цена ошибки". Без "для си". Совершенно не принципиально на каком языке ты облажаешься, есть шанс что что-то пыхнет, бахнет, пойдет вразнос, завоняет и сгорит и проч. Си в таких вещах используют специфично. Например полностью статичное распределение памяти, так что память и закончиться не может. Если это вообще скомпилилось, будет работать как батарейка энерджайзер. Хотя особо креативные програмеры могут попробовать выжрать стэк (ЧСХ это катит в большинстве ЯП, с той или иной степенью неочевидности). В параноидальных случаях еще и страхуются от прилетов частиц. Некоторые мк используют память с ECC. Софт периодически переписывает критичные регистры на случай bit flip. Ты может и не в курсе но в обычном писюке 1-2 бита в год переворачиваются сами по себе, за счет космических частиц или мощных помех. Если ты в контру шпилил это пофигу, а если оно чем-то управляло, это уже менее приятно. Софт может параноидально проверять правильность вызова своих частей (диапазоны параметров, magic values на месте). Рассматривают достаточно странные виды сбоев. Например частица может сбить program counter. Выполнение влетит на произвольный участок кода. Собственно хитрые проверки это и поймают. А если там кода не было? Для этого рекомендуют заполнять пустое место опкодами вызывающими немедленное исключение (BAD OPCODE) у железа, если проц так умеет (приветы AVR'ам которые так не умеют). Но фаны rust о такой фигне наверняка даже в проекте не задумываются. За них рантайм подумает, аж два раза. > Да и в поездах многие используют https://www.seas.gwu.edu/~mfeldman/ada-project-summary.html#... Там еще и про арианов написано, которые ракеты. Одна из них таки грохнулась из-за ошибки в софте - ЕКА попало на 2 миллиарда. Впрочем на чем именно был написан сбойнувший модуль еще смотреть надо. > И автомобиля у меня нет далеко не из-за C. Тут это наверное оффтопик.
	Ответить | Правка | ^ к родителю #131 | Наверх | Cообщить модератору

	140. "Серия уязвимостей в ядре OpenBSD"	–1 +/–
	Сообщение от Comdiv (ok) on 19-Июл-16, 14:45
	>> насколько мне известно, в этой отрасли предпочитают язык Ada > Ты вот прямо за всю начинку, от всех производителей расписываешься на чем > они там это наворачивают? Если бы я сказал - "я знаю точно, что в этой отрасли используют исключительно Ada",  тогда Ваш вопрос был бы уместен, но я сказал иное. Вот, можете оценить, кто использует Ada в авиации: https://www.seas.gwu.edu/~mfeldman/ada-project-summary.html#... Даже Туполев засветился. > Можно поспорить что там навалом и сишных > фирмварей в куче микроконтроллеров (коих напихано много и повсеместно). Управлять кофеваркой тоже нужно. Впрочем, ценой большИх усилий, можно задействовать и в критических областях. > Совершенно не принципиально > на каком языке ты облажаешься, есть шанс что что-то пыхнет, бахнет, От всех ошибок ни язык, ни архитектура не спасёт, но это не значит, что нужно использовать менее ошибкоустойчивые инструменты, в том числе и язык. > так не умеют). Но фаны rust о такой фигне наверняка даже > в проекте не задумываются. За них рантайм подумает, аж два раза. При чём тут Rust, спроектированный для создания браузера. Здесь уместней уже не раз упомянутый язык Ada. И другие люди тоже учитывают озвученные Вами факторы. Не думаете же Вы, что для того, чтобы это знать, нужно быть сишником? Вообще, странный подход считать остальных людей идиотами, которые рассчитывают на то, что за них будет думать рантайм.   > Там еще и про арианов написано, которые ракеты. Одна из них таки > грохнулась из-за ошибки в софте - ЕКА попало на 2 миллиарда. > Впрочем на чем именно был написан сбойнувший модуль еще смотреть надо. Это был модуль на Ada, бездумно перетащенный из ракеты предыдущего поколения с предсказуемым результатом. Кто бы знал, что французы такие раздолбаи? Тут интересно одна особенность. Ракета самоуничтожилась из-за аварийного отключения компьютера по причине арифметического переполнения в навигационном модуле. Если бы код для него был бы написан на стандартном Си, то существовал бы риск, что переполнение прошло бы незамеченным. Если бы это был основной навигационный модуль, можно было бы предсказать, куда бы полетела ракета с ошибкой в навигации? В какой город? Так что самоуничтожение - не худший исход. И повторюсь, из-за того, что язык в принципе не способен защитить от всех ошибок, это не значит, что вместо него следут использовать ещё более проблематичный инструмент.
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	159. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Аноним (??) on 28-Июл-16, 07:12
	> Вот, можете оценить, кто использует Ada в авиации: > https://www.seas.gwu.edu/~mfeldman/ada-project-summary.html#... > Даже Туполев засветился. Тут еще Эйрбас на днях засветился, в соседней новости про ядро Linux 4.7. С поддержкой ядром Linux хитрой топологии Ethernet, которая дважды-резервирована и закольцована, обладая нулевым временем failover. Вот я и думаю - где же они могут это применять с такими свойствами? Мне кажется для кофеварки такие технологии слегка избыточны. > Управлять кофеваркой тоже нужно. Впрочем, ценой большИх усилий, можно задействовать и в > критических областях. Критичные области всегда требуют больших усилий. Специфика такая. Нельзя налабать что-то на коленке и чтобы оно еще и надежным потом оказалось. > От всех ошибок ни язык, ни архитектура не спасёт, но это не > значит, что нужно использовать менее ошибкоустойчивые инструменты, в том числе и язык. Си не так уж сложно использовать безопасно. Там больше роялят методики разработки и общая паранойя разработчиков. Если этого нет - хренли толку с яп, разработчики все-равно накосячат. Образцовый пример - самолет у которого на полпути кончилось горючее. Потому что перепутали метрические и имперские единицы. Так можно даже в блокнотике облажаться, не то что в ЯП. Что все и сделали. > При чём тут Rust, спроектированный для создания браузера. Мне кажется что при всей хипстежности мозиллы они додумались мыслить хоть немного шире. > Вообще, странный подход считать остальных людей идио тами, > которые рассчитывают на то, что за них будет думать рантайм. Что вижу - то и пою. А что до ады - да, где-то используется. И тот резервированный эзернет на сях в ядре линукса - тоже где-то используется. Компанией Эйрбас. Наверное все-таки не в кофеварках - не помню что-то кофеварок такой марки. > Это был модуль на Ada, бездумно перетащенный из ракеты предыдущего поколения с > предсказуемым результатом. Видишь, оказывается даже на хваленой тобой Ada можно повесить фатальный баг и профакапить рекавери из явно проблемной ситуации и в конце концов залететь на несколько миллиардов долларов. Это IIRC самый дорогой по деньгам баг софта за всю историю человечества на данный момент. > Кто бы знал, что французы такие раздолбаи? Люди раздолбаи. Это known isssue. Требовательные к надежности применения пытаются это учесть так или иначе. > по причине арифметического переполнения в навигационном модуле. > Если бы код для него был бы написан на стандартном Си, то > существовал бы риск, что переполнение прошло бы незамеченным. А тут вопрос в том что за отключение было. Если это аппаратное исключение - то тогда вообще все-равно какой там был ЯП. Для задач в несколько миллиардов долларов можно и ASIC под задачу сделать, с аппаратными исключениями на любое переполнение в регистрах. На самом деле там почти всегда есть как минимум хардварный флаг. Его не так уж сложно проверять. Но есть нюансы: проверка на каждую математическую операцию густо разбавит программу проверками и скорость сильно провалится. > Если бы это был основной навигационный модуль, можно было бы предсказать, > куда бы полетела ракета с ошибкой в навигации? В какой город? До городов она бы врядли долетела. Посмотреть что бывает при серьезном отвале у ракеты управления можно на примере эпикфэйла в прямом эфире у роскосмоса. Там управление было без шансов - раздолбаи вбили датчик кверху ногами. Попытки ориентироваться на его показания приводили к обратному результату. > Так что самоуничтожение - не худший исход. Там обычно несколько вариантов самоуничтожения, в том числе и по команде с Земли обычно есть. > И повторюсь, из-за того, что язык в принципе не способен защитить от > всех ошибок, это не значит, что вместо него следут использовать ещё > более проблематичный инструмент. Так загвоздка в том что я вижу применение "более проблематичного" ЯП в дофига ответственных применений. И что-то я не вижу этих самых проблем в этих самых применениях от именно языка.
	Ответить | Правка | ^ к родителю #140 | Наверх | Cообщить модератору

	166. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Comdiv (ok) on 28-Июл-16, 17:04
	> Си не так уж сложно использовать безопасно. Там больше роялят методики разработки > и общая паранойя разработчиков. Почему Вы не включаете в методики разработки язык программирования? Это его важная часть. > Если этого нет - хренли толку с яп, разработчики все-равно накосячат. Всё время повторяю одно и то же, разница есть в количестве ошибок, пропущенных автоматическими средствами. Если Вы не верите в эту разницу, попробуйте программировать всё в машинных кодах, а "хренли толку с яп, разработчики все-равно накосячат"(С). Или по вашему Си - это вершина программистской мысли и дальнейшее совершенствование средств разработки бесмысленно? > Образцовый пример - самолет у которого на > полпути кончилось горючее. Потому что перепутали метрические и имперские единицы. Так Насколько я понимаю - в Ада есть возможность учесть единицы измерения, но никто не может заставить это использовать. > Видишь, оказывается даже на хваленой тобой Ada можно повесить фатальный баг Я об этом случае знал задолго до нашего разговора, так что же нового я должен был увидеть? Столько раз говорил, что уже надоело. Дело не в том, что от языка магическим образом исчезнут все ошибки, а в том, сколько ошибок может быть отловлено и не допущено автоматическими средствами. Объясняю - она не хвалёная, а банально более адекватное средство для такой задачи. > А тут вопрос в том что за отключение было. Если это аппаратное > исключение - то тогда вообще все-равно какой там был ЯП. Для Не всё равно. Стандарт Си, запрещает исключения при переполнении беззнаковых, и не регламентирует исключение для знаковых. Ada в этом плане лучше, но не сильно. > До городов она бы врядли долетела. Посмотреть что бывает при серьезном отвале > у ракеты управления можно на примере эпикфэйла в прямом эфире у > роскосмоса. Там управление было без шансов - раздолбаи вбили датчик кверху > ногами. Попытки ориентироваться на его показания приводили к обратному результату. Неужели Вы обобщаете по 1-му случаю? Откуда Вы знаете последствия всех потенциальных проблем? Вот недавно запускали боевые ракеты через територии других стран. Что могло бы бать, если бы из-за ошибки навигации ракеты бы направились вниз, а последствия наступили бы за очень короткое время, не давая возможность предотвратить их? > Там обычно несколько вариантов самоуничтожения, в том числе и по команде с > Земли обычно есть. Главное, чтобы ошибки не наложились друг на друга > Так загвоздка в том что я вижу применение "более проблематичного" ЯП в > дофига ответственных применений. И что-то я не вижу этих самых проблем > в этих самых применениях от именно языка. Если Вы собрали и обработали большое количество статистики, учитывая все важные параметры, тогда это "я вижу" имело бы большой вес. А так это может быть банальной неосведомлённостью. Нам-то об этом особо не докладывают. А вот новостей о нахождении уязвимостей, вызванных особенностями Си, хоть отбавляй. Их тоже не видите?
	Ответить | Правка | ^ к родителю #159 | Наверх | Cообщить модератору

	170. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Аноним (??) on 29-Июл-16, 07:31
	> Почему Вы не включаете в методики разработки язык программирования? Это его важная часть. Потому что большая часть этих методик нацелена на охоту на ошибки. Человеческие. А не надрачивание на ЯПы как серебряные пули. > Всё время повторяю одно и то же, разница есть в количестве ошибок, > пропущенных автоматическими средствами. И, конечно же, ты покажешь статистику по качеству кода и количеству багов? И это, а анализаторы кода для rust вообще уже есть? Типовые ошибки уже осознаны? И все такое? Или это будет из разряда "вот вы на своем проекте и попробуйте набить шишек"? Для сей за все эти десятилетия типовые проблемы были изучены и появилось немало приличных тулзов всех мастей определяющих подозрительные места в коде. > Если Вы не верите в эту разницу, попробуйте программировать всё в машинных кодах, Я пробовал программировать машины в кодах. И могу заассемблить на тетрадном листочке по даташиту. А ты это вообще умеешь? Или это тоже голое теоретизирование? Вообще, в современных многозадачках идея такая что обычная программа не должна мочь нанести серьезный урон системе и ядру, а сглючить саму себя - программа всегда может что так что эдак. > а "хренли толку с яп, разработчики все-равно накосячат"(С). До некоторой степени так и есть. В компиляторах бывают баги, вплоть до того что компилятор может оптимизировать так хорошо что удалит проверку NULL. Сделав нормальный код бажным. Торвальдс очень радовался. Еще компиляторы имеют свойство генерить похабный код в местах где скорость была критична. Поэтому до сих пор в кодеках, криптографии и т.п. используют ассемблерные вставки. И разница может быть в 2-3 раза. Когда один кодек легко играет FullHD, а другой дергается на 720p - выбор очевиден. Но у ассемблера есть фатальный недостаток: не портабелен. Реюз кода невозможен. Си в этом плане очень удачную нишу занял. Он еще не очень сильно пакостит но уже портабелен и при желании может стать и довольно высокоуровневым. А еще компиляторы лучше делают глобальные оптимизации. Но это важно только на большом куске кода и не отменяет того факта что компилер может выдать черти-что в тугом цикле, убив скорость алгоритма. > Или по вашему Си - это вершина программистской мысли > и дальнейшее совершенствование средств разработки бесмысленно? По нашему мнению Си очень адаптивная штука. Он может быть низкоуровневым, но на нем можно и HTTP сервер и гуйную прогу в 10-20 строк, не хуже Go'пников и питонистов. На нем можно писать почти все. Это не всегда оптимально, но так можно, он не будет мешаться и иногда это позволяет сманеврировать без диких затрат на приличное изучение другого ЯП. А безопасность и предсказуемость имхо больше всего зависят от размера проекта и качества и количества подцепленых библиотек. У DJB проект будет безопасен на чистом си, даже не MISRA. А у хипстеров типа тебя - я бы на твоем автопилоте летать зассал на любом ЯП, т.к. видел достаточно. > Насколько я понимаю - в Ада есть возможность учесть единицы измерения, но > никто не может заставить это использовать. Там была человеческая лажа, она языконезависима. Но бортовой компьютер интегрированный с картами мог бы и проделать некую валидацию (иррелевантно к ЯП). Это чисто логическая ошибка: двуногие перепутали юниты. Все мыслимые проверки это не заметили. FAIL. > может быть отловлено и не допущено автоматическими средствами. Объясняю - она > не хвалёная, а банально более адекватное средство для такой задачи. А Элон Маск - неадекват? Ну или тот же Эйрбас с его странным эзернетом. > Не всё равно. Стандарт Си, запрещает исключения при переполнении беззнаковых, и не > регламентирует исключение для знаковых. Ada в этом плане лучше, но не сильно. Для проблемо-ориентированной области можно принять свои джентльменские соглашения, что стандарт стандартом, а кастомный CPU заэскалирует до exception, врубится обработчик. Бажные программы будут пойманы. А то что стандарт разрешает - так и с указателями по стандарту можно работать. А по соглашениям MISRA C - нельзя. Чекер завернет. Не вижу в чем криминал если в проце аппаратный чекер даст по рукам за нарушение джентльменских соглашений. Да, это дополнительное ограничени поверх стандарта - нельзя полагаться на переполнение. Чем отличается от того же MISRA C? > Неужели Вы обобщаете по 1-му случаю? Я могу прикинуть что в случае ракет аэродинамика штука злая. И ракета или ведет себя более-менее прилично, или ее порвет воздухом в плотных слоях. Если не порвало, значит это уже высоко и очень приличные скорости. Тогда выгорит при reentry в атмосферу. Собственно, отработаные ступени один фиг сбрасывают и куда упадет то что не догорело при reentry известно очень приблизительно, падение неуправляемо. Стараются чтобы это было в пустынной местности, но все-таки шансы получить остатками отработанной ступени по черепу - не нулевые. > могло бы бать, если бы из-за ошибки навигации ракеты бы направились > вниз, а последствия наступили бы за очень короткое время, не давая > возможность предотвратить их? Если на то пошло, более 50% авиационных проблем случается из-за багов двуногих в кабине. Это вообще самый забагованный элемент системы. Пожалуй софтварные баги, особенно сишные, все-таки не главный бич человечества. > Главное, чтобы ошибки не наложились друг на друга Для этого принимают множество мер. Ошибки все-равно могут случаться. Но есть много инженерных и организационных принципов позволяющих минимизировать это и в крайнем случае хотя-бы избежать тяжелых последствий ("fail safe"). Военные, кстати, далеко не всегда придерживаются failsafe. Оружие создано для разрушения, захват мощного оружия посторонними считается нежелательным событием и там может быть все ровно наоборот. И поэтому уповать на то что военная ракета будет failsafe - очень оптимистично. Кроме того военная техника делается на убой и поэтому там сверхнадежность самоцель не всегда и не у всех. > может быть банальной неосведомлённостью. По тебе вообще заметно что ты осведомлен сугубо своими теоретизированиями на песке. Поэтому на твой софт я бы в mission critical применениях уповать не стал бы, на любом ЯП. > Нам-то об этом особо не докладывают. А вот новостей о нахождении уязвимостей, > вызванных особенностями Си, хоть отбавляй. Их тоже не видите? Я не знаю кому вам и что не докладывают, а я интересуюсь у коллег их смежных областей как они работают и какие технологии применяются. Себя я не считаю достаточно крутым для сверх-требовательных применений, но вполне могу получить предъявы от клиентов за заметные им сбои и поэтому предпринимаю усилия чтобы все работало как часы, выполняло задачи и не создавало проблем.
	Ответить | Правка | ^ к родителю #166 | Наверх | Cообщить модератору

	171. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Comdiv (ok) on 30-Июл-16, 22:16
	> Потому что большая часть этих методик нацелена на охоту на ошибки. Человеческие. > А не надрачивание на ЯПы как серебряные пули. С каких пор? Языки разрабатываются и совершенствуются в том числе для поиска человеческих ошибок. А мир серебряных пуль и осиновых кольев - это мифический мир фанатиков с любой стороны. И тех, что уверены будто могут создать нечто подобное и тех, что любое действие по совершенствованию заведомо объявляют "задрачиванием". > И, конечно же, ты покажешь статистику по качеству кода и количеству багов? Несмотря на сложность статистичекого сравнения разных языков в серьёзных проектах, такое исследование было проведено для Си и Ада и было опубликовано в 1995. Найти его не составляет труда, но не думаю, что оно может быть Вам полезно, о чём говорит то самодовольство с которым был задан этот "риторический" вопрос. Кроме того, инженер отличается от амёбы тем, что способен анализировать и моделировать, а не только пропускать через пищеварительную систему. > Для сей за все эти десятилетия типовые проблемы были изучены и появилось немало > приличных тулзов В число таких "тулзов" входят компиляторы других языков. Упорство, с которым Вы клоните к тому, что важно всё кроме языка, поражает. >> Если Вы не верите в эту разницу, попробуйте программировать всё в машинных кодах, > Я пробовал программировать машины в кодах. И могу заассемблить на тетрадном листочке > по даташиту. А ты это вообще умеешь? Или это тоже голое теоретизирование? Моё предложение не о том, умеете ли Вы программировать в машинных кодах, а о том, не будет ли от этого страдать качество. Одна весомая задача, один короткий срок, но возможность выбрать между машинным кодом и Си. Важен язык или нет? >> Или по вашему Си - это вершина программистской мысли > По нашему мнению Си очень адаптивная штука. Это не отвечает на вопрос, может ли быть что-то лучше Си в той же нише, или это в принципе невозможно, так как Си - оптимум? > У DJB проект будет безопасен на > чистом си, даже не MISRA. А у хипстеров типа тебя - > я бы на твоем автопилоте летать зассал на любом ЯП, т.к. видел достаточно. Оставляю Ваши неуёмные "телепатические" фантазии на Вашей совести. >> не хвалёная, а банально более адекватное средство для такой задачи. > А Элон Маск - неадекват? Ну или тот же Эйрбас с его > странным эзернетом. Тут проблемы с логикой. Использование менее адекватного(менее, а не полностью - отличайте нюансы) средства может быть продиктовано большим количеством причин, а не только глобальной неадекватностью. Если говорить конкретно про Элона Маска, то его уровень проектирования, скорее всего, куда выше языка программирования вообще и Си в частности. О том, что Си менее адекватен для критических задач написано даже в так часто здесь поминаемом MISRA C. Этот фрагмент из редакции 1998 года настолько прекрасен в контексте нашего разговора, что не могу не привести: > Nonetheless, it should be recognised that there are other languages > available which are in general better suited to safety-related systems, > having (for example) fewer insecurities and better type checking. > Examples of languages generally recognised to be more suitable than C > are Ada and Modula 2. If such languages could be available for a > proposed system then their use should be seriously considered in preference to C. > Для проблемо-ориентированной области можно принять свои джентльменские соглашения, что Тут есть другая проблема. Необходимость помнить о том, что используешь не совсем такой Си тоже опасно с точки зрения старых привычек. Об это также есть упоминание в MISRA. > А то что стандарт разрешает - так и с указателями по стандарту можно работать. > . А по соглашениям MISRA C - нельзя. Вы перепутали 1 - работу с указателями в целом с 2 - арифметикой указателей и динамической памятью. 1-е разрешено, 2-е - нет. > это дополнительное ограничени поверх стандарта - нельзя полагаться на > переполнение. Чем отличается от того же MISRA C? Тем, что это изменение семантики арифметики беззнаковых чисел, а не просто ограничение использования каких-то возможностей, наличие которых элементарно запрещается автоматически. Арифметика указателей и функции стандартного доступа к динамической памяти режется на уровне синтаксиса. Для арифметики же в общем случае, сложно определить будет ли переполнение вообще, и если будет, что это - ошибка или задумка разработчика. Можно предположить, что именно поэтому такого изменения нет в самой MISRA C. В целом, идея правильная, но не для C. > Я могу прикинуть что в случае ракет аэродинамика штука злая. Наивно полагаться на это. Переполнение может произойти в части, ответственной не за разворот на 180 градусов, а за корректировку курса на доли градуса. Это может привести к существенному отклонению от курса без критический проблемы со стороны аэродинамики. Пространство ошибок - огромно, и оно должно быть обложено со всех сторон. Полагаться на то, что и так сойдёт с надеждой на аэродинамику из-за того, что в любимом языке не учли этого - инфантилизм. > баги, особенно сишные, все-таки не главный бич человечества. Их всё равно нужно исправлять > По тебе вообще заметно что ты осведомлен сугубо своими теоретизированиями на песке. > Поэтому на твой софт я бы в mission critical применениях уповать > не стал бы, на любом ЯП. Вы так и не увидели новостей об уязвимостях, вызванных именно свойствами Си и продолжаете изображать из себя Пифию? Кстати, создатели MISRA C тоже теоретизировали на песке, предлагая использовать более подходящий язык для критических решений? Про амёб я тоже уже упоминал.
	Ответить | Правка | ^ к родителю #170 | Наверх | Cообщить модератору

	76. "Серия уязвимостей в ядре OpenBSD"	–3 +/–
	Сообщение от Comdiv (ok) on 15-Июл-16, 23:18
	С начала этого года я занялся улучшением безопасности сишных программ в нашем отделе, в первую очередь - программ для защиты данных. Главный продукт моей деятельности - это библиотека для "secure" кодирования на Си, которая должна стать стандартом для нашей компании. Вы очень грубы, но, в целом, я привык к подобному отношению со стороны коллег, которое, впрочем, они не высказывают в столь безобразной форме при личном общении. Поскольку безопасность кода на Си - это моя основная профессиональная забота, то приходится разбираться в вопросе. Уж извините, получилось так, что я понимаю о чём говорю. Вот смотрите, arisu, https://www.securecoding.cert.org/confluence/display/c/SEI+C... правила для "secure" кодирования на Си, написанные в результате анализа настоящих уязвимостей. Часть проблем, вроде целочисленного переполнения и порчи памяти решается довольно простыми средствами чисто на уровне языка. А это весомый кусок уязвимостей, как вы знаете. Причём, по большому счёту, 1-е опасно тем, что часто приводит ко 2-му. Где это используется? Вы наверно слышали, про уязвимости Stagefright в Android, которые нашумели в прошлом году? Вот код исправления одной из дырок, которая позволяла получить несанкционированный доступ к устройству https://android.googlesource.com/platform/frameworks/av/+/24...^!/#F0 Такая маленькая, а такая гадкая, и решается, повторюсь, на уровне языка. Так разумно ли для безопасных программ, в том числе ОС, использовать Си, arisu?
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	83. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Zarat (ok) on 16-Июл-16, 01:20
	Считаете, Тео, который взял ядро NetBSD, заявил об ориентации на безопасность, и не переписавший весь код на очередном "безопасном" языке, не разумным? Мир не черно-белый, в нем есть оттенки
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	85. "Серия уязвимостей в ядре OpenBSD"	–1 +/–
	Сообщение от Comdiv (ok) on 16-Июл-16, 02:43
	Между разумностью человека и разумностью поступка есть разница. Для начала нужно перестать делать ошибки в логике и устраивать ловушки оппонентам с помощью некорректных вопросов. То, что мир не делится на чёрное и белое, я знаю. Он делится на нолики и единички. Если же серьёзно, то оценка этого поступка Тео будет зависеть от точки зрения. С точки зрения усилий для достижения результата - не разумно. С религиозной точки зрения, когда вся тусовка будет осуждать тебя за отступления от идеалов Си, то вполне разумно. Кстати, о безопасности. В этой заметке я описал о легкой возможности подмены sudo  в GNU/Linux c целью повышения полномочий и получения пароля пользователя http://comdivbyzero.blogspot.ru/2016/01/big-mistake-in-using... В OpenBSD ее нет?
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	93. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Zarat (ok) on 16-Июл-16, 09:33
	Если человек последователен в поступках и поступок является частью последовательной линии поведения человека (а не набухался и натворил), то между поступком и человеком можно ставить знак равенства (человек бухает). Я считаю. Особенностью управления, как деятельности, является невозможность сравнения альтернатив. То есть, Тео принял какое-либо решение, а как бы было при альтернативах - неизвестно. А оценку Тео думаю все же стоит производить с его точки зрения. По моему логично. В той степени в которой позволяет собственное сознание. Чтобы не скатиться в мнение, что Тео дурак, OpenBSD ненужна, потому, что я ей не пользуюсь и это дурная трата внемени на очередное ненужно. А вот что нужно, я конечно же точно знаю (чем заниматься Тео). Так вот, с точки зрения усилий для достижения результата - разумно. Сомневають, что он бы нашел достаточно единомышленников, которые бы впряглись преписывать ОС на другом языке и достиг бы сегодняшнего результата. Это все конечно же ИМХО, по тому, что _бы_. Но опыт подсказывает... По поводу статьи, интересно, но в руководствах по безопасности часто рекомендуется делать хомяк с опцией noexec, что вроде решает указанные вами проблемы, включая sudo, без горожения предложенных вами костылей. А если код злоумышленника может исполняться с правами пользователя, то у него достаточно других возможностей для получения пароля пользователя. По моему это очевидно. Пользователь скомпроментирован и все тут. Знаменитая фраза с сайта OpenBSD, во первых гарантирует отсутствие только _ремотных_ уязвимостей, во вторых только в установке по умолчанию. Они не могут гарантировать безопасность от кривых рук админа, что вроде тоже очевидно. К сожалению я не читал книг "Absolute OpenBSD" и "Secure Architectures with OpenBSD", но если предложенные в них методы настройки системы косвенно не решают затронутые в вашей статье проблемы, тогда это будет действительно упущение. Увы, опровергнуть не могу, не обладаю должной квалификацией
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	100. "Серия уязвимостей в ядре OpenBSD"	–1 +/–
	Сообщение от Comdiv (ok) on 16-Июл-16, 14:06
	> Если человек последователен в поступках и поступок является частью последовательной линии > поведения человека то между поступком и человеком можно ставить знак равенства Нельзя. Во-первых, человек многогранен, и ошибка в одном вопросе не делает его дураком. Во-вторых, зачастую, последующие действия являются лишь следствием предыдущих. Иногда у людей есть смелость идти дальше, иногда - нет. > Сомневають, > что он бы нашел достаточно единомышленников, которые бы впряглись преписывать ОС > на другом языке и достиг бы сегодняшнего результата. Именно это я и имел ввиду про тусовку. > По поводу статьи, интересно, но в руководствах по безопасности часто рекомендуется делать > хомяк с опцией noexec, что вроде решает указанные вами проблемы, включая > sudo, без горожения предложенных вами костылей. Во-первых, по умолчанию эта опция не включена(в GNU/Linux). Во-вторых, она не всем подходит, например, разработчикам и просто людям пишущим или запускающим скрипты. > А если код злоумышленника может > исполняться с правами пользователя, то у него достаточно других возможностей для > получения пароля пользователя. По моему это очевидно. Пользователь скомпроментирован > и все тут. Нет. Есть класс уязвимостей, нацеленных на повышение полномочий, и их исправляют вне зависимости от наличия возможностей проникновения. Защита должна быть всесторонней.
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	103. "Серия уязвимостей в ядре OpenBSD"	–1 +/–
	Сообщение от Comdiv (ok) on 16-Июл-16, 16:53
	Установил OpenBSD, чтобы проверить наличие описанной мной проблемы PATH переменной. Не знаю, что там в книгах, но в системе по умолчанию - всё отлично работает. В переменной PATH сразу же включён каталог $HOME/bin , приглашая пользователся к запуску из домашнего каталога. No exec, как же. Более того, даже путь к установщику пакетов прописывается с помощью переменной окружения PKG_PATH и нет требования добавления удостоверяющих ключей. Такого нет даже в "более дырявой" GNU/Linux. Не хочу огорчать, но защищённость OpenBSD и, вообще, всех UNIX-образных сильно преувеличена, и объясняется по большей части принципом неуловимого Джо и более высоким уровнем среднего пользователя.
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	106. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Michael Shigorin (ok) on 16-Июл-16, 17:40
	> В переменной PATH сразу же включён каталог $HOME/bin, приглашая пользователся > к запуску из домашнего каталога. No exec, как же. Если Вы и впрямь не поняли, что только что сравнили тёплое с мягким -- попробуйте всё-таки смонтировать /home с опцией noexec, а затем попробовать воспользоваться таким "приглашением".
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	111. "Серия уязвимостей в ядре OpenBSD"	–2 +/–
	Сообщение от Comdiv (ok) on 16-Июл-16, 19:07
	> Если Вы и впрямь не поняли, что только что сравнили тёплое с мягким > попробуйте всё-таки смонтировать /home с опцией noexec, а затем > попробовать воспользоваться таким "приглашением". Спасибо за совет, без Вас я бы ни за что не разобрался с тёплым и мягким. Если Вы и впрямь не поняли о чём было моё сообщение, то ... Ладно, попытаюсь объяснить. Я отвечал на сообщение, в котором были слова >только в установке по умолчанию. Они не могут гарантировать >безопасность от кривых рук админа, что вроде тоже очевидно Тем не менее выяснилось, что в установке по умолчанию домашний каталог не только не заблокирован для исполнения, но и более того, содержимое переменной PATH говорит о том, что это считается нормальным и домашний каталог даже в приоритете перед системным. И это в серверной ОС, ориентированной на защищённость. Повторюсь, такого даже в "менее защищённой" GNU/Linux нет.
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	119. "Серия уязвимостей в ядре OpenBSD"	–2 +/–
	Сообщение от Сырный дух on 17-Июл-16, 16:12
	Вообще не понимаю, в чём проблема с sudo и прочими suid-утилитами, кроме получающих пароль с консоли. Подменяя их, как можно навредить? Настоящая sudo не выполнит ничего, кроме разрешённого в конфиге. Подменять её нет смысла. su, passwd, другие программы, ловящие пароль - да, это опасно. Опять же PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/home/cheesespirit/bin И?
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	121. "Серия уязвимостей в ядре OpenBSD"	–1 +/–
	Сообщение от Comdiv (ok) on 17-Июл-16, 17:06
	> Вообще не понимаю, в чём проблема с sudo и прочими suid-утилитами, кроме > получающих пароль с консоли. Подменяя их, как можно навредить? Настоящая sudo > не выполнит ничего, кроме разрешённого в конфиге. Подменять её нет смысла. > su, passwd, другие программы, ловящие пароль - да, это опасно. Опять же По умолчанию во многих дистрибутивах, sudo требует пароль и позволяет выполнять всё. > PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/home/cheesespirit/bin > И? Злонамеренный код может изменить PATH по своему усмотрению.
	Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

	122. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Сырный дух on 17-Июл-16, 19:45
	>> Вообще не понимаю, в чём проблема с sudo и прочими suid-утилитами, кроме >> получающих пароль с консоли. Подменяя их, как можно навредить? Настоящая sudo >> не выполнит ничего, кроме разрешённого в конфиге. Подменять её нет смысла. >> su, passwd, другие программы, ловящие пароль - да, это опасно. Опять же > По умолчанию во многих дистрибутивах, sudo требует пароль и позволяет выполнять всё. // не в тему треда, но в перманентного тему холивара на этой сайте // голосом зазывалы на ярмарке А вот кто хочет поругать винду за запрос админ.пароля на Secure desktop? >> PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/home/cheesespirit/bin >> И? > Злонамеренный код может изменить PATH по своему усмотрению. Отсюда вывод (давно уже известный, но всё же) - администратору нельзя пользоваться клиентскими учётками, а только своими, проверенными. Ну или, да, как Вы говорите, в недоверенном окружении всё проверять и писать абсолютные пути. Кстати, в Вашу копилку... не забывать, что правильно использовать такие ключи к su: su --login su -l su - хотя, вроде бы без этого path всё равно переопределяется, вот другие переменные не всегда. Возможны неожиданные побочные эффекты.
	Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

	123. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Andrey Mitrofanov on 17-Июл-16, 20:07
	> По умолчанию во многих дистрибутивах, sudo требует пароль и позволяет выполнять всё. >> И? > Злонамеренный код может изменить PATH по своему усмотрению. И вставить 'rm -rf /;' перед командными параметрами перед передачей настоящему sudo. Патч Бармина -- Юбунту Эдишон. Повеяло. Свежо!
	Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

	129. "Серия уязвимостей в ядре OpenBSD"	+1 +/–
	Сообщение от Аноним (??) on 18-Июл-16, 23:42
	> По умолчанию во многих дистрибутивах, sudo требует пароль и позволяет выполнять всё. С повышенными правами - только "административному" пользователю который систему ставил. Иначе как в такой системе вообще что-то администрировать? Пароль рута отсутствует и под ним не зайдешь. Поэтому и. Остальным пользователям это не полагается, покуда админ не пропишет их в конфиг самолично. Читай конфиги sudo.
	Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

	132. "Серия уязвимостей в ядре OpenBSD"	–1 +/–
	Сообщение от Comdiv (ok) on 19-Июл-16, 00:40
	И что не так? Компьютеры сейчас действительно персональные. Сам поставил - сам пользуешься. Сам разгребаешь проблемы.
	Ответить | Правка | ^ к родителю #129 | Наверх | Cообщить модератору

	160. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Аноним (??) on 28-Июл-16, 07:18
	Расскажи это хотя-бы тем же хостерам с их контейнерами и виртуалками.
	Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

	143. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Аноним (??) on 20-Июл-16, 00:46
	> Установил OpenBSD, чтобы проверить наличие описанной мной проблемы PATH переменной. Не > знаю, что там в книгах, но в системе по умолчанию - > всё отлично работает. В переменной PATH сразу же включён каталог $HOME/bin > , приглашая пользователся к запуску из домашнего каталога. No exec, как > же. Всё так. > Более того, даже путь к установщику пакетов прописывается с помощью переменной окружения > PKG_PATH и нет требования добавления удостоверяющих ключей. > Такого нет даже в "более дырявой" GNU/Linux. А вот здесь не так (если, конечно, у вас не древний релиз). Ключи уже лежат в /etc/signify. Будете ставить из левого репозитория, или неподписанный пакет — вас предупредят.
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	147. "Серия уязвимостей в ядре OpenBSD"	–1 +/–
	Сообщение от Comdiv (ok) on 20-Июл-16, 01:17
	Ясно, спасибо за уточнение. То есть, этой переменной задаётся адрес только одного и зеркал официального репозитория? Сторонние репозитории поддерживаются?
	Ответить | Правка | ^ к родителю #143 | Наверх | Cообщить модератору

	150. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Аноним (??) on 24-Июл-16, 00:57
	> Ясно, спасибо за уточнение. То есть, этой переменной задаётся адрес только одного > и зеркал официального репозитория? Сторонние репозитории поддерживаются? В этой переменной, как и в /etc/pkg.conf, можно задать любое количество репозиториев. Тем более, что репозиторий - просто папка, без всяких хитрых структур и индексных карт. Официальные пакеты подписываются официальными же ключами, но вы можете подписывать свои пакеты своими. pkg_add сама разбирается, что к чему, и предупреждает при попытке установить пакет, подпись у которого отсутствует или не верифицируема (ключа нет в /etc/signify).
	Ответить | Правка | ^ к родителю #147 | Наверх | Cообщить модератору

	152. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Аноним (??) on 27-Июл-16, 01:03
	> Установил OpenBSD, чтобы проверить наличие описанной мной проблемы PATH переменной. Не > знаю, что там в книгах, но в системе по умолчанию - > всё отлично работает. В переменной PATH сразу же включён каталог $HOME/bin > , приглашая пользователся к запуску из домашнего каталога. No exec, как > же. А вообще давайте подумаем. Если атакующий может положить свой файл в ФС (а это требуется, чтобы пользователь ввёл "sudo" и запустил при этом что-то левое)... ... то он может перезаписать ~/.profile... ... поместив в него код, распаковывающий/компилирующий программу, которая прикидывается шеллом, но при этом обрабатывает ввод пользователя самостоятельно. И чихать хотела на любой $PATH. Так что, получается, ~/bin в конце $PATH — не панацея, а так, защита от script kiddies. Не?
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	153. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Comdiv (ok) on 27-Июл-16, 01:24
	> Если атакующий может положить свой файл в ФС (а это требуется, чтобы > пользователь ввёл "sudo" и запустил при этом что-то левое)... > ... то он может перезаписать ~/.profile... > Так что, получается, ~/bin в конце $PATH — не панацея, а так, > защита от script kiddies. Не? Вообще-то я писал об этом в заметке блога во 2-м пункте - необходимо сменить пользователя файлов .bashrc и .profile и запретить запись другим. Неудобно, когда нужно редактировать, но это редко случается.
	Ответить | Правка | ^ к родителю #152 | Наверх | Cообщить модератору

	154. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Аноним (??) on 27-Июл-16, 03:18
	>> Если атакующий может положить свой файл в ФС (а это требуется, чтобы >> пользователь ввёл "sudo" и запустил при этом что-то левое)... >> ... то он может перезаписать ~/.profile... >> Так что, получается, ~/bin в конце $PATH — не панацея, а так, >> защита от script kiddies. Не? > Вообще-то я писал об этом в заметке блога во 2-м пункте - > необходимо сменить пользователя файлов .bashrc и .profile и запретить запись другим. > Неудобно, когда нужно редактировать, но это редко случается. А это уже слишком неудобно. Чрезмерно неудобное же будет проигнорировано — закон жизни. К тому же всё равно не спасёт: возможность писать в ФС от имени пользователя даёт массу других возможностей. Особенно на десктопе, где используется масса ПО различной степени дырявости (зачастую ещё и не обновляемом — особенно этим страдают как раз пользователи *nix, среди которых многие уверены, что бояться им нечего). И которому ПО только дай повод прочитать какой-нибудь специально покорёженный файл, чтобы позволить выполнить произвольный код... А там уже можно и, скажем, системный хоткей переназначить на «свою программу», и окно терминала обернуть в своё, забирая весь клавиатурный ввод, и вообще всё, что угодно. И это у меня ещё с фантазией плохо. Так что сценарий «наш процесс взломали» сам по себе уже является финитой. Тут могут помогать разве что средства вроде Linux capabilities или OpenBSD-шного pledge.
	Ответить | Правка | ^ к родителю #153 | Наверх | Cообщить модератору

	155. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Comdiv (ok) on 28-Июл-16, 00:09
	>> необходимо сменить пользователя файлов .bashrc и .profile и запретить запись другим. > А это уже слишком неудобно. Чрезмерно неудобное же будет проигнорировано — закон > жизни. Что тут слишком неудобного? Если сменили владельца на root, то: $ /usr/bin/sudo editor ~/.bashrc Да и это редко нужно. > К тому же всё равно не спасёт: возможность писать в > ФС от имени пользователя даёт массу других возможностей. Особенно на десктопе, > где используется масса ПО различной степени дырявости (зачастую ещё и не > обновляемом — особенно этим страдают как раз пользователи *nix, среди которых > многие уверены, что бояться им нечего). Вы серьёзно? В дистрибутивах GNU/Linux обновление настолько удобное, что не обновляться просто глупо. Я таких людей не знаю. > А там уже можно и, скажем, системный хоткей переназначить > на «свою программу» Запускайте свой терминал из защищённого от записи ярлыка. >, и окно терминала обернуть в своё, забирая весь > клавиатурный ввод, и вообще всё, что угодно. Расскажите, как Вы оборачивать его собрались? Или это было пояснение про горячие клавиши? > Так что сценарий «наш процесс взломали» сам по себе уже является финитой. Нет. Сливать воду можно лишь тогда, когда вас заказали специалистам. В противном случае - блокировка даже простейших возможностей - уже неплохое подспорье. Зловреды не обладает искусственным интеллектом и большинство из них используют наиболее простые решения. А зачем напрягаться, если большинство и в ус не дует, поскольку считают, что и так всё пропало.
	Ответить | Правка | ^ к родителю #154 | Наверх | Cообщить модератору

	156. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Comdiv (ok) on 28-Июл-16, 00:14
	>[оверквотинг удален] >> клавиатурный ввод, и вообще всё, что угодно. > Расскажите, как Вы оборачивать его собрались? Или это было пояснение про горячие > клавиши? >> Так что сценарий «наш процесс взломали» сам по себе уже является финитой. > Нет. Сливать воду можно лишь тогда, когда вас заказали специалистам. В противном > случае - блокировка даже простейших возможностей - уже неплохое подспорье. Зловреды > не обладает > искусственным интеллектом и большинство из них используют наиболее простые решения. А зачем > напрягаться, если большинство и в ус не дует, поскольку считают, что > и так всё пропало.
	Ответить | Правка | ^ к родителю #155 | Наверх | Cообщить модератору

	105. "Серия уязвимостей в ядре OpenBSD"	+1 +/–
	Сообщение от Michael Shigorin (ok) on 16-Июл-16, 17:11
	> Кстати, о безопасности. В этой заметке я описал о легкой возможности подмены > sudo  в GNU/Linux c целью повышения полномочий и получения пароля > пользователя http://comdivbyzero.blogspot.ru/2016/01/big-mistake-in-using... "Я не специалист по компьютерной безопасности"... вот что предлагает известный специалист: http://www.opennet.dev/openforum/vsluhforumID3/73378.html#19 А так может оказаться проще и удобней обойтись без манипуляции PATH, просто воткнувшись в ~/bin/, который нередко бывает первым в $PATH (хотя у нас в альте первым идёт /usr/bin, где и лежит тот же бинарник sudo).
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	108. "Серия уязвимостей в ядре OpenBSD"	–1 +/–
	Сообщение от Comdiv (ok) on 16-Июл-16, 17:56
	>вот что предлагает известный специалист Это больше подходит для серверных ОС. Безопасность нужна и на рабочих станциях.
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	144. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Аноним (??) on 20-Июл-16, 00:50
	> А так может оказаться проще и удобней обойтись без манипуляции PATH, просто > воткнувшись в ~/bin/, который нередко бывает первым в $PATH (хотя у > нас в альте первым идёт /usr/bin, где и лежит тот же > бинарник sudo). В OpenBSD так же, $HOME/bin идёт в конце, поэтому просто перекрыть не получится. Но если злоумышленник может писать в ФС, он может и $HOME/.profile подправить...
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	115. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Анонимный Алкоголик (??) on 17-Июл-16, 03:07
	> Кстати, о безопасности. В этой заметке я описал о легкой возможности подмены > sudo  в GNU/Linux c целью повышения полномочий и получения пароля > пользователя http://comdivbyzero.blogspot.ru/2016/01/big-mistake-in-using... > В OpenBSD ее нет? И многим со своей лёгкой возможностью уже подменили? Как мы понимаем вас не затруднит внедрить трояна к нам, ведь у вас такая лёгкая возможность... :-)
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	117. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Comdiv (ok) on 17-Июл-16, 11:40
	> И многим со своей лёгкой возможностью уже подменили? Зачем? Меня интересует конструктивная деятельность. Я указал, что нужно сделать, чтобы этого не происходило. Те, кто подменяют, делают это молча, пока жертва уверена, что работает в системе, у которой нет проблем с безопасностью.
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

	118. "Серия уязвимостей в ядре OpenBSD"	–1 +/–
	Сообщение от Led (ok) on 17-Июл-16, 15:38
	> Меня интересует конструктивная деятельность. Иди в винду, ламер.
	Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

	120. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Comdiv (ok) on 17-Июл-16, 17:00
	В феерической логике Вам не откажешь.
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	128. "Серия уязвимостей в ядре OpenBSD"	–1 +/–
	Сообщение от Аноним (??) on 18-Июл-16, 23:22
	> В феерической логике Вам не откажешь. Грубо говоря, переключиться в режим хакера и подумать "а как бы я это ломал?" - самый эффективный способ жизнь этим самым хакерам усложнить. А если ты так не умеешь - как и от чего ты будешь защищаться, чудак? Глядя на твои потуги хакеры умрут со смеха и зайдут с направления которое ты даже не предусмотрел.
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	133. "Серия уязвимостей в ядре OpenBSD"	–1 +/–
	Сообщение от Comdiv (ok) on 19-Июл-16, 00:41
	Всего не предусмотришь, но что предусмотрел - стоит исправить.
	Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

	161. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Аноним (??) on 28-Июл-16, 07:24
	> Всего не предусмотришь, но что предусмотрел - стоит исправить. Чтобы уметь предусматривать - надо понимать как системы атакуют и какие техники при этом используются. Защита от сферических угроз в вакууме неэффективна. Ты будешь строить бункер с пятиметровыми стенами. Хакер на это посмотрит, обнаружит что крышу посторить забыли и уссываясь закинет туда кирпич. И какая тебе будет радость от твоих пятиметровых стен, если ты олух и каску не одел?
	Ответить | Правка | ^ к родителю #133 | Наверх | Cообщить модератору

	167. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Comdiv (ok) on 28-Июл-16, 17:25
	> Чтобы уметь предусматривать - надо понимать как системы атакуют и какие техники > при этом используются. Защита от сферических угроз в вакууме неэффективна. Странная логика. Если Вы знаете как системы атакуют - то они должны быть защищены от этого по умолчанию. Но на этом нельзя останавливаться. Не думаете же Вы, что злоумышленники удовлетворятся неудачной попыткой, и не станут разрабытвать новые средства? Они как раз и заняты превращением сферических угроз в вакууме в действительно используемые. Вот тут недавно исследователи испытали сферичечкую угрозу - пакеты в репозиториях языков разработки с опечатками в названиях известных библиотек. Результаты - прекрасные. Я так понимаю, по Вашему, так делать не стоило и нужно было ждать, когда этим станут массово пользоваться злоумышленники, и только затем предпринимать какие-то действия? > Ты будешь строить бункер с пятиметровыми стенами. Хакер на это посмотрит, обнаружит > что крышу посторить забыли и уссываясь закинет туда кирпич. Опять что-то с логикой. Я как раз такой пример с недостроенной крышей и привёл. А Вы о чём?
	Ответить | Правка | ^ к родителю #161 | Наверх | Cообщить модератору

	104. "Серия уязвимостей в ядре OpenBSD"	+1 +/–
	Сообщение от Michael Shigorin (ok) on 16-Июл-16, 17:05
	> Главный продукт моей деятельности - это библиотека для "secure" кодирования на Си Знаете, даже у такого сишного чайника как я, на этом месте брови вверх поползли. Вы всерьёз собираетесь решать организационную проблему техметодами?  Если вдруг так, то на Вашем месте я бы прислушался к грубому, но в целом верному мнению arisu (сишника со стажем) -- уж лучше пусть хоть так предупредят, что моста нет, чем выяснять на собственном опыте. Пассаж про ОС порадовал втройне -- Ваши предложения чего-либо выше макроассемблера вроде C для *ядра*? PS: нет, в нашей glibc есть strl*(), например.  Но в чём-то прав и Дреппер.
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	110. "Серия уязвимостей в ядре OpenBSD"	–1 +/–
	Сообщение от Comdiv (ok) on 16-Июл-16, 18:26
	>> Главный продукт моей деятельности - это библиотека для "secure" кодирования на Си > Вы всерьёз собираетесь решать организационную проблему техметодами?   Естественно нет, где Вы это увидели?. Но организационные методы, как ни странно, требуют технической поддержки. Именно поэтому в компиляторах есть такие ключи как -W, именно поэтому создаются статические анализаторы, именно поэтому создаются стандарты вроде MISRA C и инструменты проверки на соответствие им, и именно поэтому создаются такие библиотеки для "безопасного" кодирования. Поинтересуйтесь, зачем библиотеки для шифрования создают собственные функции на замену стандартным. > на Вашем месте я бы прислушался к грубому, но в целом > верному мнению arisu (сишника со стажем) Какая польза от подобных мнений? Никакой. Напомню крайне полезное мнение: >>дебилу типа тебя завсегда что‐нибудь мешает. то штаны, то язык > Пассаж про ОС порадовал втройне -- Ваши предложения чего-либо выше макроассемблера вроде > C для *ядра*? Я уже писал об этом. Низкоуровневые возможности должны использоваться в изолированном месте, а не быть размазанными по языку. Практическая реализуемость этого подхода была доказана в 1988 году на примере Oberon OS. В промышленности использовалась, например, операционная система Jbed, написанная на диалекте Oberon-языка. Помимо изоляции низкоуровневости, язык в целом должен быть более адекватно скроен.
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	145. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Аноним (??) on 20-Июл-16, 00:54
	>>> Главный продукт моей деятельности - это библиотека для "secure" кодирования на Си >> Вы всерьёз собираетесь решать организационную проблему техметодами? > Естественно нет, где Вы это увидели?. Но организационные методы, как ни странно, > требуют технической поддержки. Именно поэтому в компиляторах есть такие ключи как > -W, именно поэтому создаются статические анализаторы, именно поэтому создаются стандарты > вроде MISRA C и инструменты проверки на соответствие им, и именно > поэтому создаются такие библиотеки для "безопасного" кодирования. Поинтересуйтесь, зачем > библиотеки для шифрования создают собственные функции на замену стандартным. А вы поинтересуйтесь, например, почему разрабы LibreSSL и BoringSSL первым делом выпилили такие прослойки в виде собственных функций из OpenSSL. Подсказка: потому что они не планировали работать на VMS.
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	148. "Серия уязвимостей в ядре OpenBSD"	–1 +/–
	Сообщение от Comdiv (ok) on 20-Июл-16, 01:47
	Не знаю, что такое VMS, но судя по функциям timingsafe_memcmp, explicit_bzero, strlcpy, strlcat и т.д. в LibreSSL они вполне используют некое подобие secure coding library.
	Ответить | Правка | ^ к родителю #145 | Наверх | Cообщить модератору

	151. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Аноним (??) on 24-Июл-16, 01:02
	> Не знаю, что такое VMS, https://ru.wikipedia.org/wiki/OpenVMS > но судя по функциям timingsafe_memcmp, explicit_bzero, strlcpy, > strlcat и т.д. в LibreSSL они вполне используют некое подобие secure > coding library. Да, это фирменные наработки OpenBSD. А вот то, что было выпилено, было не secure coding library, а банальными механизмами абстракции и костылями для различных мёртвых систем в виде перереализованных стандартных интерфейсов Си. И в этих слоях абстракции скрывались целые стада граблей...
	Ответить | Правка | ^ к родителю #148 | Наверх | Cообщить модератору

	112. "Серия уязвимостей в ядре OpenBSD"	+1 +/–
	Сообщение от Comdiv (ok) on 16-Июл-16, 19:55
	>Но в чём-то прав и Дреппер. Дреппер - это разработчик glibc? Конечно, он прав, кто ж спорит. Вот он прав http://www.opennet.dev/opennews/art.shtml?num=43886 с критической уязвимостью из-за переплонения буфера в getaddrinfo Вот он прав http://www.linux.org.ru/news/security/4057482/page1 с критической уязвимостью из-за арифметического переполнения в strfmon Вот он прав http://www.securitylab.ru/analytics/470861.php с критической уязвимостью из-за переполнения буфера в куче в __nss_hostname_digits_dots. Это хороший советчик по безопасному кодированию, да. Авторитет.
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	125. "Серия уязвимостей в ядре OpenBSD"	+1 +/–
	Сообщение от dq0s4y71 (??) on 18-Июл-16, 19:19
	> Вы очень грубы, но, в целом, я привык к подобному отношению со стороны коллег... То есть, мы в вас не ошиблись.
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	135. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Аноним (??) on 19-Июл-16, 02:28
	Судя по частому упоминанию оберона, это сектант.
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

	149. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Comdiv (ok) on 20-Июл-16, 01:59
	> Судя по частому упоминанию оберона, это сектант. Логика феерическая. На самом деле, люди постоянно спрашивают и ошибочно утверждают одно и то же, вот одно и то же и отвечаю. Добрей к людям надо быть, аноним.
	Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

	8. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от qeqwe on 15-Июл-16, 11:55
	Выбирая C ты со 99% уверенностью можешь сказать что то что ты написал, так и произойдет. А если поубирать оптимизации то и на 100% можно. А тот-же Rust он достаточно сложный в плане реализации, что ведет к проблемам на уровне компилятора и реализации.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	11. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Аноним (??) on 15-Июл-16, 12:35
	Знал бы ты, чувак, сколько раз я писал в багзиллу gcc об багах в компиляторе. Так что у тебя херня вместо логики, прости.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	20. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Аноним (??) on 15-Июл-16, 15:58
	> Знал бы ты, чувак, сколько раз я писал в багзиллу gcc об > багах в компиляторе. Так что у тебя херня вместо логики, прости. Если rust'ом кто-то всерьез начнет пользоваться для чего-то системного, а не очередных неуловимых proof of concept, которыми никто не пользуется и поэтому никто не находит баги - баги gcc будут цветочками, а ягодки будут собирать пользователи rust.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	34. "Серия уязвимостей в ядре OpenBSD"	+3 +/–
	Сообщение от Аноним (??) on 15-Июл-16, 16:23
	Прежде, чем писать о баге в компиляторе - потрудитесь изучить компилируемый им язык. (c) Лао-Цзы (источник на китайском был, перевод - вольный).
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	47. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Аноним (??) on 15-Июл-16, 16:46
	> (c) Лао-Цзы (источник на китайском был, перевод - вольный). Проблема цитат в интернете в том, что люди сразу верят в их истинность (с) В.И. Ленин
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	51. "Серия уязвимостей в ядре OpenBSD"	+2 +/–
	Сообщение от _ (??) on 15-Июл-16, 16:52
	А в наще время верить никому нельзя! Мне - можно! (С) Мюллер
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	48. "Серия уязвимостей в ядре OpenBSD"	+3 +/–
	Сообщение от _ (??) on 15-Июл-16, 16:48
	>Знал бы ты, чувак, сколько раз я писал в багзиллу gcc об багах в компиляторе. То что ты умеешь писать ... по крайней мере обнадёживает, да :) >Так что у тебя херня вместо логики, прости. А у тебя ... хмм ... логика вместо херни 8-о Багзилы других Ёзыгов так и стоят пустыми?! ORLY!? :-)
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	16. "Серия уязвимостей в ядре OpenBSD"	–1 +/–
	Сообщение от rob pike on 15-Июл-16, 14:25
	> со 99% уверенностью можешь сказать что то что ты написал, так и произойдет > А если поубирать оптимизации то и на 100% можно Это смотря что писать. Иногда и понимания протокола MOESI маловато будет.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	77. "Серия уязвимостей в ядре OpenBSD"	–2 +/–
	Сообщение от Comdiv (ok) on 15-Июл-16, 23:25
	К сожалению, нет. Одна из фундаментальных проблем Си - это то, что интуитивное понимание Си и его формальное описание довольно сильно отличаются. Вот, к примеру, (-1 < 1u) является ложным утверждением. Но для многих - это сюрприз.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	84. "Серия уязвимостей в ядре OpenBSD"	–1 +/–
	Сообщение от Zarat (ok) on 16-Июл-16, 01:32
	Это не фундаментальная проблема С, это проблема манагеров, верящих, что программирование - это легко, и "программистов", устраивавшихся на работу к тем манагерам, после прочитения книг типа "С за 21 день". Раньше это была проблема отрасли, когда на рынке присутствовали молодые хакеры "знающие" крутой С (С++) и манагеры, которые потом выбирали "энтерпрайзный" С для проектов, а не, например, Паскаль. Сейчас понапридумывали и разрекламировали разных Java, C#, и язык С сузил свою нишу применения, и проблема сгладилась, оставшись в легаси.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	86. "Серия уязвимостей в ядре OpenBSD"	–1 +/–
	Сообщение от Comdiv (ok) on 16-Июл-16, 02:57
	Проблема сгладилась лишь там, где его перестали использовать. Где присутствует Си - присутсвует и проблема в том же объёме, что и раньше. Мне приходится иметь дело с тоннами прекрасного кода, написанного молодыми хакерами, не понимающих, что они делают не так, а потому уверенных, что ничего кроме Си и не надо. Ведь они профессионалы.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	94. "Серия уязвимостей в ядре OpenBSD"	–1 +/–
	Сообщение от Zarat (ok) on 16-Июл-16, 09:41
	Мог бы вам посочувствовать, только думаю, что вам это не нужно :) Но опять же, это не проблема Си, а проблема управления, выбора, руководства, легаси и т.д.
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	107. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Michael Shigorin (ok) on 16-Июл-16, 17:43
	> и манагеры, которые потом выбирали "энтерпрайзный" С для проектов Эт когда? > а не, например, Паскаль. Эт зачем? > Сейчас понапридумывали и разрекламировали разных Java, C# Ничего, что тот же лисп немного старше, а "понапридумывали" ещё как минимум VB из "паскалей, только типа уже не учебных"? :)
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	90. "Серия уязвимостей в ядре OpenBSD"	–1 +/–
	Сообщение от Анонимный Алкоголик (??) on 16-Июл-16, 05:49
	> К сожалению, нет. Одна из фундаментальных проблем Си - это то, что > интуитивное понимание Си и его формальное описание довольно сильно отличаются. > Вот, к примеру, (-1 < 1u) является ложным утверждением. Но для многих > - это сюрприз. Но это потому что у этих многих отсутствует понимание C. А не потому что оно у них отличается от какого-то там формального описания. И данная проблема к числу (фундаментальных) проблем C никак не относится. Для многих непонимающих всякие минус единицы эта дискуссия тоже где-то сюрприз...
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	98. "Серия уязвимостей в ядре OpenBSD"	–1 +/–
	Сообщение от Comdiv (ok) on 16-Июл-16, 13:49
	> Но это потому что у этих многих отсутствует понимание C. > А не потому что оно у них отличается от какого-то там формального описания. Между этими утверждениями нет противоречия.
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	114. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Анонимный Алкоголик (??) on 17-Июл-16, 02:39
	Вас это столь поразило, что вы не смогли не отметить сей факт отдельным комментарием? :-)
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	116. "Серия уязвимостей в ядре OpenBSD"	–1 +/–
	Сообщение от Comdiv (ok) on 17-Июл-16, 11:35
	Увидел противоречие в противопоставлении непротиворечивых утверждений - указал на это. Что Вас удивляет?
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

	95. "Серия уязвимостей в ядре OpenBSD"	+1 +/–
	Сообщение от Аноним (??) on 16-Июл-16, 11:47
	> Вот, к примеру, (-1 < 1u) является ложным утверждением. Но для многих - это сюрприз. Какой же это сюрприз если тут warning будет?
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	99. "Серия уязвимостей в ядре OpenBSD"	–2 +/–
	Сообщение от Comdiv (ok) on 16-Июл-16, 13:50
	>> Вот, к примеру, (-1 < 1u) является ложным утверждением. Но для многих - это сюрприз. > Какой же это сюрприз если тут warning будет? По умолчанию - нет. И многие ведут разработку, не обращая внимания на предупреждения.
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	10. "Серия уязвимостей в ядре OpenBSD"	+8 +/–
	Сообщение от Аноним (??) on 15-Июл-16, 12:34
	> Сам по себе выбор языка Си для создания ОС уже говорит достаточно об отношеннии к безопасности. Язык программирования который собственными средствами не может вызвать крах системы не пригоден для создания ОС
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	13. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Аноним (??) on 15-Июл-16, 13:09
	Полностью с Вами согласен.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	31. "Серия уязвимостей в ядре OpenBSD"	–1 +/–
	Сообщение от Аноним (??) on 15-Июл-16, 16:21
	> Язык программирования который собственными средствами не может вызвать крах системы не  пригоден для создания ОС То есть, нельзя вот так взять и написать ОС на баше? Фанаты unix way скорбят.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	46. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Аноним (??) on 15-Июл-16, 16:46
	> То есть, нельзя вот так взять и написать ОС на баше? Когда в баш добавят средства для записи в произвольные места памяти и научат ассемблерным вставкам, тогда, может быть, и будет можно. > Фанаты unix way скорбят. Какое отношение баш имеет к unix-way? Эта поделка под такое определение точно не попадает. И как шелл-скриптопускалка и как интерактивная оболочка он достаточно убог
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	50. "Серия уязвимостей в ядре OpenBSD"	–2 +/–
	Сообщение от Аноним (??) on 15-Июл-16, 16:51
	> Когда в баш добавят средства для записи в произвольные места памяти и научат ассемблерным вставкам, тогда, может быть, и будет можно. Эти возможности нарушают ключевые принципы философии UNIX - "простота и прозрачность". Какая может простота при ручных манипуляциях с памятью? А прозрачность в ассемблерных листингах? (Особенно для человека, который знает три с половиной команды в шелле, и больше ничего учить не считает нужным.) > Какое отношение баш имеет к unix-way? Эта поделка под такое определение точно не попадает. И как шелл-скриптопускалка и как интерактивная оболочка он достаточно убог csh, конечно, более тру, но в наше время большинство UNIX-философов про него не в курсе. Вообще, главное - чтобы именно шелл, потому что без него прозрачность™ обеспечить крайне проблематично.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	53. "Серия уязвимостей в ядре OpenBSD"	–1 +/–
	Сообщение от _ (??) on 15-Июл-16, 17:00
	>Эти возможности нарушают ключевые принципы философии UNIX - "простота и прозрачность". UNIX предоставляет простота и прозрачность для пользователя. Что там будет внутри - простым и прозрачным сделать не обещали :) >Какая может простота при ручных манипуляциях с памятью? А что может быть проще? ;-) >А прозрачность в ассемблерных листингах? (Особенно для человека, который знает три с половиной команды в шелле, и больше ничего учить не считает нужным.) А зачем такой человек решил писать ОС? На шелле? Пусть проспится, а поутру, взяв метлу займётся тем, в чём он - проффесионал. >csh, конечно, более тру, но в наше время большинство UNIX-философов про него не в курсе. Интересно ты школоту назвал ... а отцы основатели про этот шелл писали что то типо: ... никогда! ... НИКОГДА!!! не бзайте csh для написания скриптов! Зрада, хлопчик! :)
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	109. "Серия уязвимостей в ядре OpenBSD"	+1 +/–
	Сообщение от Michael Shigorin (ok) on 16-Июл-16, 17:56
	>> Фанаты unix way скорбят. > Какое отношение баш имеет к unix-way? Сдаётся мне, это был очередной виндостудент (именно так) с фиксацией на так и не понятом юниксвее из методички...
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	78. "Серия уязвимостей в ядре OpenBSD"	–1 +/–
	Сообщение от Comdiv (ok) on 15-Июл-16, 23:38
	Если Вы имеете ввиду необходимость средств для низкоуровневой работы с железом, то тут есть нюанс. Для предоставления этой возможности язык не обязан вшивать её в свой фундамент, а может ограничивать в относительно небольших кусках кода, ограждая её от большей части, сохраняя устойчивость от низкоуровневых ошибок. Так было сделано в Oberon OS ещё в 1988 году, а производные этой системы были пригодны даже для настоящего времени(RTOS). Общество довольно инерционно, но всё же не стоит на месте, поэтому когда-нибудь оно перестанет мучать идеи конца 60-х и начнёт использовать идеи 80-х. Прогресс неумолим.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	88. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от rob pike on 16-Июл-16, 03:07
	Всё хорошо в Обероне кроме его фанатов. По сравнению с ними растеры это толерантнейшие, милейшие, открытейшие ко всему многообразию точек зрения люди.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	89. "Серия уязвимостей в ядре OpenBSD"	–1 +/–
	Сообщение от Comdiv (ok) on 16-Июл-16, 03:24
	Фанатизм везде плох.
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	82. "Серия уязвимостей в ядре OpenBSD"	–2 +/–
	Сообщение от Zarat (ok) on 16-Июл-16, 00:58
	> Openbsd - это сама сесюрность! Она не уязвима. Не перед чем! Никогда. Где тут отсутствие "сесюрности"? OpenBSD правильно сработала (в ущерб надежности) и не позволила эскалировать уязвимости. По количеству плюсов, можно увидеть сколько здесь не ошибающихся ничего не делающих борщехлебов. Куда катится Opennet?
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

5. "Серия уязвимостей в ядре OpenBSD"	–9 +/–
Сообщение от arisu (ok) on 15-Июл-16, 11:43
всего пять. опёнок всё‐таки очень хорош.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	17. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от rob pike on 15-Июл-16, 14:27
	Поэтому все облачные сервисы строятся именно на его основе.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	18. "Серия уязвимостей в ядре OpenBSD"	+1 +/–
	Сообщение от grsec (ok) on 15-Июл-16, 15:27
	Чего?
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	33. "Серия уязвимостей в ядре OpenBSD"	+1 +/–
	Сообщение от rob pike on 15-Июл-16, 16:23
	</sarcasm>
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	37. "Серия уязвимостей в ядре OpenBSD"	+3 +/–
	Сообщение от Аноним (??) on 15-Июл-16, 16:32
	> </sarcasm> На форуме с буратиной не всегда понятно, где сарказм, а где человек искренне так считает.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	24. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Аноним (??) on 15-Июл-16, 16:13
	> Поэтому все облачные сервисы строятся именно на его основе. Где-то прорвало черную дыру - у нас визитеры из другой вселенной.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	27. "Серия уязвимостей в ядре OpenBSD"	+1 +/–
	Сообщение от Аноним (??) on 15-Июл-16, 16:16
	>> Поэтому все облачные сервисы строятся именно на его основе. > Где-то прорвало черную дыру - у нас визитеры из другой вселенной. Вполне допускаю, что наш бедный буратино сделал себе на серваке под диваном облачный сервис на основе опенка, и никому его не показывает (для безопасности). В пределах квартиры буратины можно утверждать, что "все облачные сервисы строятся именно на его основе".
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	65. "Серия уязвимостей в ядре OpenBSD"	+1 +/–
	Сообщение от Аноним (??) on 15-Июл-16, 18:06
	Понятно, масштаб прорыва оказался преувеличен.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	49. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от _ (??) on 15-Июл-16, 16:50
	>Поэтому все облачные сервисы строятся именно на его основе. Это сарказм такой или ты ... хммм ... погорячился? :)
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

Часть нити удалена модератором

	58. "Серия уязвимостей в ядре OpenBSD"	–1 +/–
	Сообщение от _ (??) on 15-Июл-16, 17:22
	Сынок ... тут такая штука ... нет ни одного большого проекта, который "пришел к успеху" без такого стиля руководства +\- сапог советский кирзовый ... _Должен_ быть человек который может "завершать дискуссии аргументом я так сказал, и так будет, ибо." ... или закончим "демократическим голосованием в стиле Дебиан" ... что ещё хуже :( Тот чел должен нести за свой выбор ответственность. Если ошибся - выпрут на следующих выборах. И вот это - работает. Не забывай, в опен сорсе - ты не в рабстве, не нравится - форкайся, вливай своё видение в проект и ... и к следующим выборам сам народ назначит тебя на царство :)
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	63. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Аноним (??) on 15-Июл-16, 17:48
	> Наверное, привычкой завершать дискуссии аргументом "я так сказал, и так будет, ибо." Ну а что, технически все так и есть. Ты можешь форкнуть/написать свое/пойти на и в/вписать свой вариант. А указывать им что делать ты не сможешь чисто технически. Поэтому ты или сможешь выкатить забойные аргументы своей правоты или пойдешь лесом. И даже то что ты хоть трижды прав еще никого ни к чему само по себе не обязывает.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

9. "Серия уязвимостей в ядре OpenBSD"	–1 +/–
Сообщение от Аноним (??) on 15-Июл-16, 12:28
Нашил - и спасибо! Опенок стал еще безопаснее.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	14. "Серия уязвимостей в ядре OpenBSD"	–1 +/–
	Сообщение от Аноним (??) on 15-Июл-16, 13:09
	> Нашил - и спасибо! Опенок стал еще безопаснее. Нашил, пожалуйста.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	22. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Аноним (??) on 15-Июл-16, 16:11
	>  Нашил - и спасибо! Опенок стал еще безопаснее. В линуксе с каждым релизом столько дырок устраняют, и что он уже лет десять как должен быть самым безопасным.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	59. "Серия уязвимостей в ядре OpenBSD"	–1 +/–
	Сообщение от _ (??) on 15-Июл-16, 17:31
	Боюсь подумать на каком недостигаемом уровне тогда форточка 8-D
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	102. "Серия уязвимостей в ядре OpenBSD"	–1 +/–
	Сообщение от Аноним (??) on 16-Июл-16, 16:41
	в моем андроиде дыры все прибавляются залатать никак, секуребут, ваще печаль
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	162. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Аноним (??) on 28-Июл-16, 07:28
	> в моем андроиде дыры все прибавляются залатать никак, секуребут, ваще печаль Так получи рута через дыры и обдури секурбут :)
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

12. "Серия уязвимостей в ядре OpenBSD"	+1 +/–
Сообщение от Аноним (??) on 15-Июл-16, 12:40
> Проблемы > уже оперативно устранены (http://www.openbsd.org/errata59.html) в кодовой базе OpenBSD. Надо глянуть, у них до сих пор попытка установить таймер с 0-й задержкой через kqueue приводит к жесткому lockup-у или уже пофиксили... А то в отсутствие пользовательских kevent-ов в этой чудесной системе даже нечем просигналить в событийную петлю.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	15. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Ivan_83 (ok) on 15-Июл-16, 13:43
	У фри есть юзерский тип фильтров, там наверное тоже. Но проще сделать пайп, читающий конец в событийную петлю, а в пишуший писать, так есть гарантия что два разных сигнала пришедших одновременно туда попадут.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	29. "Серия уязвимостей в ядре OpenBSD"	+1 +/–
	Сообщение от Аноним (??) on 15-Июл-16, 16:18
	В опенке и в нет-е нет юзерского типа и в обоих не работают таймеры с 0-й задержкой, в опенке до кучи еще и систему вешают. Поэтому, да, приходится извращаться с пайпами, слава БГ-у они хоть количество байт доступных в data пишут, сразу видно сколько читать надо. А юзерные и таймерные события обычно по ident-у проще различать т.к. одновременно они, как-правило, из разных источников приходят.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	73. "Серия уязвимостей в ядре OpenBSD"	–1 +/–
	Сообщение от Ivan_83 (ok) on 15-Июл-16, 20:42
	Да, с произвольными идентами тамймеров это великое удобство kqueue(), с epoll() приходится извращаться. С точки зрения производительности пайпы лучше: они один раз созданы и работают пока нужны, а таймеры каждый раз аллоцируются в ядре, лишняя бесполезная работа.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

64. "Серия уязвимостей в ядре OpenBSD"	–1 +/–
Сообщение от Дегенератор on 15-Июл-16, 18:03
раньше было 5-10 патчей за год. Сейчас 20 за 3 месяца. Зато досрочно релизнули. В инструкциях к патчам опечатки и относительные пути. Они бухать что-ли начали. Это капец какой-то.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	66. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Дегенератор on 15-Июл-16, 18:07
	http://ftp.openbsd.org/pub/OpenBSD/patches/5.7/common/002_li... cd /usr/xenocara/lib/libXont http://ftp.openbsd.org/pub/OpenBSD/patches/5.9/common/005_cr... And then rebuild and install libcrypto:     cd src/lib/libcrypto
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	67. "Серия уязвимостей в ядре OpenBSD"	+2 +/–
	Сообщение от Аноним (??) on 15-Июл-16, 18:09
	> раньше было 5-10 патчей за год. Сейчас 20 за 3 месяца. Ускорение разработки в целых 8 раз, между прочим. Только подумайте, 800% ускорения. Несложные вычисления подсказывают что примерно через 2500 лет OpenBSD захватит вселенную.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	91. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от ПолковникВасечкин on 16-Июл-16, 08:51
	У тебя ошибка. 8 раз это 700%. Пересчитай .
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	69. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Дегенератор on 15-Июл-16, 18:26
	На calomel.org несколько лет назад были инструкции для OpenBSD типа "установил и заБил"))). Она сама качала исходники, компилила, обновлялась и т.д. - полная автономность. Как думаете почему этой инструкции сейчас нет?
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	70. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от rob pike on 15-Июл-16, 19:04
	AS400 себе детали сама заказывала на замену.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	72. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Дегенератор on 15-Июл-16, 20:28
	почитал http://www.osp.ru/lan/1997/04/132698/ Вот вещи делали...
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	75. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от rob pike on 15-Июл-16, 21:07
	Почитайте лучше "Inside the AS/400", она и на русский переводилась.
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	96. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Аноним (??) on 16-Июл-16, 11:58
	> Вот вещи делали... Никому не нужные :-)
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	113. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от rob pike on 17-Июл-16, 02:18
	>  Bill Gates commented that the only part of IBM that Microsoft would be interested in was the AS/400 division. (At the time, many of Microsoft's business and financial systems ran on the AS/400 platform)
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	164. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Аноним (??) on 28-Июл-16, 07:35
	Ну и где теперь MS, а где IBM и AS/400? А financial systems скоро будут одним сплошным блокчейном. Там требования к надежеости сильно ниже - блокчейн априори реплпцирован на всех. Вы с вашими финансовыми системами всего лишь горстка ископаемых из прошлого тысячелетия.
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	163. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Аноним (??) on 28-Июл-16, 07:31
	> AS400 себе детали сама заказывала на замену. Нашел чем удивить. Скоро холодильники будут сами закавыать продукты.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	146. "Серия уязвимостей в ядре OpenBSD"	+/–
	Сообщение от Аноним (??) on 20-Июл-16, 01:01
	> На calomel.org несколько лет назад были инструкции для OpenBSD... Искренне советую на этом бросать читать. Этот сайт — сборище хаутушек с описанием работы в протухших версиях Опёнка, с зачастую попросту вредными советами. Даже нынешний Хабр по уровню в среднем получше будет.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

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

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