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

Критическая уязвимость в  OpenSSL 1.1.0a, opennews (ok), 26-Сен-16, (0) [смотреть все] Почему в критически важных программах до сих пор используют указатели, а не пров, iZEN (ok), 17:46 , 26-Сен-16, (1) –11 // Потому что в критически важных программах особенно в криптографии критически в, Аноним (-), 17:54 , 26-Сен-16, (4) +9   // Как использование ссылок вместо указателей влияет на производительность , Аноним (5), 18:25 , 26-Сен-16, (5) +1   // Ты дурак OpenSSL написан на С, откуда там ссылки , Аноним (-), 18:57 , 26-Сен-16, (12) –1   Управляемый язык подразумевает виртуальную машину Вот есть Java SSL, например, , KonstantinB (ok), 21:38 , 26-Сен-16, (22) –2   C не является управляемым языком, однако ссылки там есть, вывод - надо писать , anonymous (??), 21:40 , 26-Сен-16, (23) –1   Вы так говорите, как будто в C нельзя сделать dangling reference Есть, конечно, KonstantinB (ok), 21:46 , 26-Сен-16, (24) +3   Rust , Аноним (-), 00:04 , 27-Сен-16, (34)   Разве что теоретически - если вообще всё на нем вообще переписать, не используя , KonstantinB (ok), 02:34 , 27-Сен-16, (47) +3   Настолько категорично переписывать всё и не обязательно 8211 даже с unsafe-ом, Аноним (-), 15:10 , 27-Сен-16, (78) +4   Многие проекты на C переносятся на плюсы переименованием файлов в cpp, и добавл, Аноним (5), 15:23 , 27-Сен-16, (80)   Может всё же не стоит путать пренос кода на другой язык с подключением этого же , Аноним (-), 15:39 , 27-Сен-16, (83) +3   Тут некоторые аргументируют выбор языка в пользу С его производительностью, необ, Аноним (5), 17:01 , 27-Сен-16, (86) –1   D , Клыкастый (ok), 11:28 , 27-Сен-16, (66)   Его главная проблема в том, что он метит скорее к высокоуровенным языкам, и в пл, Аноним (-), 17:06 , 27-Сен-16, (87) +1   высокоуровневые это C он от сишника недалеко ушёл, и вынос некоторых вещей на у, Клыкастый (ok), 17:40 , 27-Сен-16, (88) –2   Нет, не использует Ну, точнее есть самая наивная реализация самртпоинтеров в ст, Аноним (-), 18:26 , 27-Сен-16, (92) +1   по хабрам и D-пабликам ходит статья про обёртки для работы с отключеным GC, не о, Клыкастый (ok), 12:11 , 28-Сен-16, (104) –1   Бред _ptr s и smart_ptr не имеют к GC никакого отношения Все сводится к по, anonymous (??), 09:35 , 29-Сен-16, (112) –1   Может стоит сначала открыть исходники и посмотреть прежде чем писать Или объясни, Аноним (-), 11:08 , 29-Сен-16, (113)   Именно так Вам стоит таки открыть исходники , yaa (?), 11:23 , 29-Сен-16, (114) –1   https github com dlang phobos blob master std typecons d L5016Ну , Аноним (-), 16:26 , 29-Сен-16, (115)   А, так речь про D Тогда все эти комментарии надо потереть , yaa (?), 19:46 , 29-Сен-16, (116)   Если какие-либо Ваши потеряли смысл после уточнения -- приведите их номера, пожа, Michael Shigorin (ok), 19:55 , 29-Сен-16, (117)   Теперь D принято писать так -DПотому что не взлетели , _ (??), 18:11 , 27-Сен-16, (90) –2   Так зачем писать фигню, а потом её компилить и релизить , Аноним (-), 09:53 , 27-Сен-16, (59)   Но в Go как-то решили обе эти проблемы Или нет http golang-book ru chapter-08, iZEN (ok), 00:46 , 27-Сен-16, (40) –6   // http benchmarksgame alioth debian org u64q compare php lang go lang2 gcc, angra (ok), 02:37 , 27-Сен-16, (49)   Результат предсказуем прежде всего из-за слабенького по сравнению с GCC оптими, Led (ok), 03:00 , 27-Сен-16, (51)   Если ты оптимизируешь проверки границ массивов - тормозить, конечно, перестанет,, Аноним (-), 11:58 , 27-Сен-16, (68) –2   Вы еще расскажите, что проверки границ достаточно крупных массивов обязятельно д, Аноним84701 (?), 14:31 , 27-Сен-16, (76)   Нет, не гладиолус, а по причине того, что проверка выполняется при каждой операц, angra (ok), 23:38 , 27-Сен-16, (97) –1   При последовательном обходе, копировании в из и т д mprotect , PROT_NONE на , Аноним84701 (?), 00:47 , 28-Сен-16, (99)   Массивы чаще всего используются так a i или так a i , то есть читается , angra (ok), 02:15 , 28-Сен-16, (100) –1   Нет Нужна проверка адреса на валидность перед циклом и ширины шага в самом цикл, Аноним84701 (?), 14:33 , 28-Сен-16, (105)   for i 0 i n i if smth i m a i a i-1 a i-2 b i f a i Вот тебе, angra (ok), 01:34 , 29-Сен-16, (107) –1   Ну-ну 1 То, что вариант с smth true a -1 a -2 failможно, совершен, Аноним84701 (?), 03:35 , 29-Сен-16, (108) +1   Хороший результат у Go Даже в таком виде , Аноним (-), 10:23 , 27-Сен-16, (61)   Хороший, не спорю, но Изя то говорил про полное решение проблем с производительн, angra (ok), 10:49 , 27-Сен-16, (65) –1   Потому что C - это религия , Аноним (-), 18:25 , 26-Сен-16, (6) –10 // Никогда не считал себя религиозным фанатиком, но ты мне не нравишься ушёл соби, Какаянахренразница (ok), 03:06 , 27-Сен-16, (53) +5 OpenSSL написан на сишечке, там ссылок нет, Аноним (5), 18:26 , 26-Сен-16, (7) –1 Проверяемые кем Висячие ссылки не менее реальны, чем висячие указатели И потом, Аноним (-), 18:28 , 26-Сен-16, (8) +8 // Он даже в джаве теоретик, что перед ним бисер метать , Аноним (-), 19:42 , 26-Сен-16, (15) +2 Потому, что ссылка, указатель и адрес в памяти есть тождественные синонимы одног, КО (?), 22:51 , 26-Сен-16, (27) +3 Потому что ссылки это C , а тупoрылые ретрограды которые пишут OpenSSL, и, кста, Аноним (-), 00:01 , 27-Сен-16, (32) –1 // Как же всё-таки безнадёжно выглядят вот такие организмы, почему-то не берущие во, Michael Shigorin (ok), 00:11 , 27-Сен-16, (37) +4 // да куеватуча бест практис по секурному кодингу на сях, видать никто не читает, п, Sw00p aka Jerom (?), 01:34 , 27-Сен-16, (43) +1 есть еще копипейст и очепятки, причём во всех языках , труляляй (?), 10:46 , 27-Сен-16, (63) +1 А можно ссылочку , аноним2 (?), 15:28 , 27-Сен-16, (82) +1 Гугл помощь, или примеру на cert org посмотри, там есть книжка по secure codin, Sw00p aka Jerom (?), 21:21 , 27-Сен-16, (94) Так я на C пишу И что-то дырок в моих проектах каждый день по десятку не нахо, Аноним (-), 11:02 , 28-Сен-16, (102) –1 Джо, но где же Ваша реализация SSL-библиотеки Может быть Только что-то уже пов, Michael Shigorin (ok), 11:41 , 28-Сен-16, (103) А уж генетический код то какой устаревший Все эти ДНК,РНК и т д УЖАСТЬ КАКО, невидимка (?), 11:45 , 27-Сен-16, (67) +2 Фак Ну сколько можно так косячить , Онаним (?), 17:47 , 26-Сен-16, (2) –1 // Если не будет постоянных багов - программисты останутся без работы Это как с по, Аноним (-), 21:14 , 26-Сен-16, (18) –3 // Вы так говорите, будто это что-то плохое , scor (ok), 23:21 , 26-Сен-16, (28) ага и касперский пишет вирусы , Sw00p aka Jerom (?), 01:36 , 27-Сен-16, (44) // fix, Аноним (-), 04:31 , 29-Сен-16, (109) Создавать новые программы для тебя не вариант Предпочитаешь паразитировать на и, angra (ok), 02:32 , 27-Сен-16, (46) +3 // Для меня - вполне себе вариант Я говорил о сишниках и об их деятельности по мно, Сторонник прогресса (?), 02:50 , 27-Сен-16, (50) –6 Как для маковода - вполне предсказуемые действия , Led (ok), 03:01 , 27-Сен-16, (52) +1 То ли дело Java программисты Только вперёд Если класс, то только с новой функци, curious (?), 10:23 , 27-Сен-16, (60) +2 К чему это или о чем , мда (?), 14:31 , 27-Сен-16, (77) Не удержался , Аноним (-), 08:45 , 29-Сен-16, (110) То есть с точки зрения эльфа баги есть только в Сишных программах На php, где н, angra (ok), 10:47 , 27-Сен-16, (64) +1 На пыхе баги в основном касаются бизнес-логики А на сишечке -- бизнес-логика , Аноним (-), 12:00 , 27-Сен-16, (69) –5 И много sql injections или csrf бывает в I бузинес-логике I всяких joomla с p, Michael Shigorin (ok), 12:23 , 27-Сен-16, (70) Причина ошибок что с sql-инъекциями, что со stack overflow, одна и та же невним, Аноним (-), 13:18 , 27-Сен-16, (71) –3 Ура Ну вот, опять сказки пошли Да-да, неломающиеся и неглючащие роботы, которы, Michael Shigorin (ok), 13:33 , 27-Сен-16, (72) +1 Повсеместное использование query-build-еров и подстановок - сказка Отнюдь Пыхе, Аноним (-), 13:48 , 27-Сен-16, (73) –3 Разница между распространением и гарантией понятна Так-то и сишные функции раб, Michael Shigorin (ok), 13:58 , 27-Сен-16, (75) Слишком жЫрно Те же prepared statements появились в рен-знает-каком году В пых, Аноним84701 (?), 13:55 , 27-Сен-16, (74) +2 Они уже умные и заранее работают с ДОСТАТОЧНОЙ эффективностью Работа как видите, Аноним (-), 15:21 , 27-Сен-16, (79) –1 Работа полицейских в плане противодействия преступности могла бы закончиться, ес, Michael Shigorin (ok), 15:27 , 27-Сен-16, (81) В моём районе есть кирпич и водители постоянно под него едут, и полицейские прие, Аноним (-), 15:49 , 27-Сен-16, (84) –2 Выясните, кто занимается выставлением дорожных знаков кажется, в моём аналогичн, Michael Shigorin (ok), 17:53 , 27-Сен-16, (89) Станислав Лем Звездные дневники Ийона Тихого Путешествие двадцать четвертое, Аноним (-), 16:28 , 27-Сен-16, (85) Там не люди что до, что после гармонизации PS но всяко спасибо , Michael Shigorin (ok), 20:06 , 27-Сен-16, (93) –1 Спасибо, посмеялся Обучаемость основной массы пыхеров это просто пять с плюсом,, angra (ok), 23:58 , 27-Сен-16, (98) +1 Может случиться в любой программе на любом языке, от незнания криворукости устал, Аноним (-), 08:47 , 29-Сен-16, (111) В следующих сериях нашего сериальчика Вы также увидите рассказы клоунов нашего с, Andrey Mitrofanov (?), 14:53 , 28-Сен-16, (106) Всем разрабам срочно нобелевскую премию за успешные попытки сделать IT мир не оч, rt (??), 17:49 , 26-Сен-16, (3) +1 Кто там в соседней теме про ха-ха писал , KM (?), 18:47 , 26-Сен-16, (9) +1 // Да тут и http www opennet ru openforum vsluhforumID3 109194 html 3 спрашивали , Michael Shigorin (ok), 19:24 , 26-Сен-16, (14) +1 // Ну а куда без неё , KM (?), 22:28 , 26-Сен-16, (26) Еще один факт, доказывающий что в OpenSSL некомпетентные люди пилят Вообще Open, eRIC (ok), 18:50 , 26-Сен-16, (10) +2 // с ситемой то будет поставляться либра, а вот половина софта из портов пакетов , Sw00p aka Jerom (?), 01:38 , 27-Сен-16, (45) // согласен, но со временем и софт с портов начнет внедрять поддержку LibreSSL , eRIC (ok), 07:01 , 27-Сен-16, (56) –1 половина в OpenBSD я недавно насчитал 6 штук или 5 причём половина из них - и, бедный буратино (ok), 07:05 , 27-Сен-16, (57) –1 Void Linux как раз на либре , kachsheev (ok), 03:25 , 27-Сен-16, (54) –1 Шикарная формулировка This security update addresses issues that were caused b, YetAnotherOnanym (ok), 18:52 , 26-Сен-16, (11) +2 ну классика - В релизе X было исправленно Y ошибок Просто о том, сколько при , ALex_hha (ok), 19:06 , 26-Сен-16, (13) –1 Нужен еще один аудит, а потом заставить всех опеннетчиков читать код или делать, Аноним (-), 21:26 , 26-Сен-16, (20) –1 // Аноним - не читатель, аноним - писатель - , KonstantinB (ok), 21:48 , 26-Сен-16, (25) +1 // Пусть эти, как их зарегистрированные читют , Andrey Mitrofanov (?), 10:39 , 27-Сен-16, (62) Буратино тоже использует OpenSSL , Аноним (-), 23:31 , 26-Сен-16, (29) // Интересно, с чего вдруг такое предположение, если ББ сидит на OpenBSD, где Libre, Аноним (-), 23:43 , 26-Сен-16, (30) // уже выпустили, за примерное поведениесва-бо-ду бу-ра-ти-нам , бедный буратино (ok), 01:22 , 27-Сен-16, (42) +1 Снова, опять , Аноним (-), 08:19 , 27-Сен-16, (58) 1,2,3,9,10,11,13,20,29,58

Сообщения

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

	4. "Критическая уязвимость в  OpenSSL 1.1.0a"	+9 +/–
	Сообщение от Аноним (-), 26-Сен-16, 17:54
	Потому что в критически важных программах (особенно в криптографии) критически важна скорость и низкое потребление памяти.
	Ответить | Правка | Наверх | Cообщить модератору

	5. "Критическая уязвимость в  OpenSSL 1.1.0a"	+1 +/–
	Сообщение от Аноним (5), 26-Сен-16, 18:25
	Как использование ссылок вместо указателей влияет на производительность?
	Ответить | Правка | Наверх | Cообщить модератору

	12. "Критическая уязвимость в  OpenSSL 1.1.0a"	–1 +/–
	Сообщение от Аноним (-), 26-Сен-16, 18:57
	Ты дурак? OpenSSL написан на С, откуда там ссылки?
	Ответить | Правка | Наверх | Cообщить модератору

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

	22. "Критическая уязвимость в  OpenSSL 1.1.0a"	–2 +/–
	Сообщение от KonstantinB (ok), 26-Сен-16, 21:38
	Управляемый язык подразумевает виртуальную машину. Вот есть Java SSL, например, и что с этим делать вне JRE-мира?
	Ответить | Правка | Наверх | Cообщить модератору

	23. "Критическая уязвимость в  OpenSSL 1.1.0a"	–1 +/–
	Сообщение от anonymous (??), 26-Сен-16, 21:40
	C++ не является управляемым языком, однако ссылки там есть, вывод - надо писать на плюсах. А то на сишечке такой код нормально компилится и ждет своего часа.     char a[256];     char *buf = a;     recv(hSocket, &buf, 256);
	Ответить | Правка | Наверх | Cообщить модератору

	24. "Критическая уязвимость в  OpenSSL 1.1.0a"	+3 +/–
	Сообщение от KonstantinB (ok), 26-Сен-16, 21:46
	Вы так говорите, как будто в C++ нельзя сделать dangling reference. Есть, конечно, smart pointers, но это решает проблемы только локально и не всегда.
	Ответить | Правка | Наверх | Cообщить модератору

	34. "Критическая уязвимость в  OpenSSL 1.1.0a"	+/–
	Сообщение от Аноним (-), 27-Сен-16, 00:04
	Rust?
	Ответить | Правка | Наверх | Cообщить модератору

	47. "Критическая уязвимость в  OpenSSL 1.1.0a"	+3 +/–
	Сообщение от KonstantinB (ok), 27-Сен-16, 02:34
	Разве что теоретически - если вообще всё на нем вообще переписать, не используя unsafe-функции и raw pointers. На практике малореализуемо. Вот что на практике реализуемо - так это использовать инструменты статического и динамического анализа и придерживаться единого стиля. Большинство проблем с openssl - следствие исторически сложившейся запутанности его кода и отсутствия этих самых best practices: когда ответственность за выделение/освобождение памяти разнесена как попало, подобные ошибки просто неизбежны. Форки типа libressl как раз это и пытаются решить.
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Критическая уязвимость в  OpenSSL 1.1.0a"	+4 +/–
	Сообщение от Аноним (-), 27-Сен-16, 15:10
	Настолько категорично переписывать всё и не обязательно – даже с unsafe-ом количество мест за которыми нужно следить сокращается многократно. Но всё же это всё мечты – переносить проект после такого длинного пути развития на plain c даже на плюсы уже целая эпопея (см. gcc).
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Критическая уязвимость в  OpenSSL 1.1.0a"	+/–
	Сообщение от Аноним (5), 27-Сен-16, 15:23
	> Настолько категорично переписывать всё и не обязательно – даже с unsafe-ом количество > мест за которыми нужно следить сокращается многократно. > Но всё же это всё мечты – переносить проект после такого длинного > пути развития на plain c даже на плюсы уже целая эпопея > (см. gcc). Многие проекты на C переносятся на плюсы переименованием файлов в .cpp, и добавлением префикса extern "C" для функций API
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Критическая уязвимость в  OpenSSL 1.1.0a"	+3 +/–
	Сообщение от Аноним (-), 27-Сен-16, 15:39
	Может всё же не стоит путать пренос кода на другой язык с подключением этого же кода к коду на другом языке?
	Ответить | Правка | Наверх | Cообщить модератору

	86. "Критическая уязвимость в  OpenSSL 1.1.0a"	–1 +/–
	Сообщение от Аноним (5), 27-Сен-16, 17:01
	> Может всё же не стоит путать пренос кода на другой язык с > подключением этого же кода к коду на другом языке? Тут некоторые аргументируют выбор языка в пользу С его производительностью, необходимой криптографическим алгоритмам. Программируя на С++ в стиле С мы не потеряем производительность и можем постепенно добавить элементы, которые есть только у С++. Теже ссылки вместо указателей, где это уместно
	Ответить | Правка | Наверх | Cообщить модератору

	66. "Критическая уязвимость в  OpenSSL 1.1.0a"	+/–
	Сообщение от Клыкастый (ok), 27-Сен-16, 11:28
	D?
	Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

	87. "Критическая уязвимость в  OpenSSL 1.1.0a"	+1 +/–
	Сообщение от Аноним (-), 27-Сен-16, 17:06
	Его главная проблема в том, что он метит скорее к высокоуровенным языкам, и в плане безопасности от тех же плюсов без использования GC не ушёл никуда.
	Ответить | Правка | Наверх | Cообщить модератору

	88. "Критическая уязвимость в  OpenSSL 1.1.0a"	–2 +/–
	Сообщение от Клыкастый (ok), 27-Сен-16, 17:40
	> Его главная проблема в том, что он метит скорее к высокоуровенным языкам, высокоуровневые это C? он от сишника недалеко ушёл, и вынос некоторых вещей на уровень стиля программирования и проверку части ошибок на компилятор не сильно его приближает к жабам и окамлам. ИМХО то, что заказывали: "низкоуровневое" как C, чуть более безопасное, как C++. Это просто мои соображения, категорично утверждать не буду. > и в плане безопасности от тех же плюсов без использования GC не ушёл никуда. насколько я знаю использует подсчёт ссылок. уже хорошо.
	Ответить | Правка | Наверх | Cообщить модератору

	92. "Критическая уязвимость в  OpenSSL 1.1.0a"	+1 +/–
	Сообщение от Аноним (-), 27-Сен-16, 18:26
	>насколько я знаю использует подсчёт ссылок. уже хорошо. Нет, не использует. Ну, точнее есть самая наивная реализация самртпоинтеров в стандартной библиотеке как и в плюсах (при этом самое смешное что использовать их с отлкюченным GC или без рантайма не получится - эта реализация взаимодействует со сборщиком, чтобы тот корректно работал). >высокоуровневые это C? он от сишника недалеко ушёл Вот вообще ни разу - без сборщика течёт половина языка (те же билтиновые массивы, строки, замыкания и тд), аллокации на стёке в самом языке нет - есть в стандартной библиотекие, которая без GC не работает :)
	Ответить | Правка | Наверх | Cообщить модератору

	104. "Критическая уязвимость в  OpenSSL 1.1.0a"	–1 +/–
	Сообщение от Клыкастый (ok), 28-Сен-16, 12:11
	> Нет, не использует. Ну, точнее есть самая наивная реализация самртпоинтеров в стандартной > библиотеке как и в плюсах (при этом самое смешное что использовать > их с отлкюченным GC или без рантайма не получится - эта > реализация взаимодействует со сборщиком, чтобы тот корректно работал). по хабрам и D-пабликам ходит статья про обёртки для работы с отключеным GC, не оно? (про ровность такого решения пока не будем). > Вот вообще ни разу - без сборщика течёт половина языка (те же > билтиновые массивы, строки, замыкания и тд), аллокации на стёке в самом > языке нет - есть в стандартной библиотекие, которая без GC не > работает :) всё так плохо?
	Ответить | Правка | Наверх | Cообщить модератору

	112. "Критическая уязвимость в  OpenSSL 1.1.0a"	–1 +/–
	Сообщение от anonymous (??), 29-Сен-16, 09:35
	Бред. ""_ptr's (и smart_ptr) не имеют к GC никакого отношения. Все сводится к подсчету ссылок (ну, и определённые гарантии по жизненному циклу объектов).
	Ответить | Правка | Наверх | Cообщить модератору

	113. "Критическая уязвимость в  OpenSSL 1.1.0a"	+/–
	Сообщение от Аноним (-), 29-Сен-16, 11:08
	Может стоит сначала открыть исходники и посмотреть прежде чем писать? Или объяснить принцип работы GC и как память выделенная внутри объекта завёрнутого в смартпоинтер отслеживается сборщиком?
	Ответить | Правка | К родителю #112 | Наверх | Cообщить модератору

	114. "Критическая уязвимость в  OpenSSL 1.1.0a"	–1 +/–
	Сообщение от yaa (?), 29-Сен-16, 11:23
	> Может стоит сначала открыть исходники и посмотреть прежде чем писать? Именно так. Вам стоит таки открыть исходники.
	Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

	115. "Критическая уязвимость в  OpenSSL 1.1.0a"	+/–
	Сообщение от Аноним (-), 29-Сен-16, 16:26
	https://github.com/dlang/phobos/blob/master/std/typecons.d#L... Ну...
	Ответить | Правка | К родителю #114 | Наверх | Cообщить модератору

	116. "Критическая уязвимость в  OpenSSL 1.1.0a"	+/–
	Сообщение от yaa (?), 29-Сен-16, 19:46
	А, так речь про D... Тогда все эти комментарии надо потереть.
	Ответить | Правка | К родителю #115 | Наверх | Cообщить модератору

	117. "Критическая уязвимость в  OpenSSL 1.1.0a"	+/–
	Сообщение от Michael Shigorin (ok), 29-Сен-16, 19:55
	> А, так речь про D... Тогда все эти комментарии надо потереть. Если какие-либо Ваши потеряли смысл после уточнения -- приведите их номера, пожалуйста.
	Ответить | Правка | К родителю #116 | Наверх | Cообщить модератору

	90. "Критическая уязвимость в  OpenSSL 1.1.0a"	–2 +/–
	Сообщение от _ (??), 27-Сен-16, 18:11
	Теперь D принято писать так: :-D Потому что не взлетели.
	Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

	59. "Критическая уязвимость в  OpenSSL 1.1.0a"	+/–
	Сообщение от Аноним (-), 27-Сен-16, 09:53
	Так зачем писать фигню, а потом её компилить и релизить?
	Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

	40. "Критическая уязвимость в  OpenSSL 1.1.0a"	–6 +/–
	Сообщение от iZEN (ok), 27-Сен-16, 00:46
	> Потому что в критически важных программах (особенно в криптографии) критически важна скорость и низкое потребление памяти. Но в Go как-то решили обе эти проблемы. Или нет? http://golang-book.ru/chapter-08-pointers.html
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	49. "Критическая уязвимость в  OpenSSL 1.1.0a"	+/–
	Сообщение от angra (ok), 27-Сен-16, 02:37
	http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Критическая уязвимость в  OpenSSL 1.1.0a"	+/–
	Сообщение от Led (ok), 27-Сен-16, 03:00
	> http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... Результат предсказуем прежде всего из-за слабенького (по сравнению с GCC) оптимизатора в Go.
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Критическая уязвимость в  OpenSSL 1.1.0a"	–2 +/–
	Сообщение от Аноним (-), 27-Сен-16, 11:58
	> Результат предсказуем прежде всего из-за слабенького (по сравнению с GCC) оптимизатора в Go. Если ты оптимизируешь проверки границ массивов - тормозить, конечно, перестанет, но тогда и проверок не будет :)
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Критическая уязвимость в  OpenSSL 1.1.0a"	+/–
	Сообщение от Аноним84701 (?), 27-Сен-16, 14:31
	>> Результат предсказуем прежде всего из-за слабенького (по сравнению с GCC) оптимизатора в Go. > Если ты оптимизируешь проверки границ массивов - тормозить, конечно, перестанет, но тогда > и проверок не будет :) Вы еще расскажите, что проверки границ достаточно крупных массивов обязятельно должны тормозить "потому что гладиолус" ;)
	Ответить | Правка | Наверх | Cообщить модератору

	97. "Критическая уязвимость в  OpenSSL 1.1.0a"	–1 +/–
	Сообщение от angra (ok), 27-Сен-16, 23:38
	Нет, не гладиолус, а по причине того, что проверка выполняется при каждой операции, так что абсолютно фиолетово какой там размер массива.
	Ответить | Правка | Наверх | Cообщить модератору

	99. "Критическая уязвимость в  OpenSSL 1.1.0a"	+/–
	Сообщение от Аноним84701 (?), 28-Сен-16, 00:47
	> Нет, не гладиолус, а по причине того, что проверка выполняется при каждой > операции, так что абсолютно фиолетово какой там размер массива. При последовательном обходе, копировании в/из и т.д: mprotect(..., PROT_NONE) на страничку памяти (или несколько, зависит от размера элементов) после массива — и ваши массивы будут мягкими и шелковистыми! Да и проверка (одна) в таком случае нужна только перед началом сего действа  и только в том случае, если собираемся проходить не с нулевого элемента. Просто "стOит" это дело одну-две дополнительные страницы памяти (т.к. "валидная" длина массива будет кратной размеру страницы памяти), и не спасет при произвольном доступе/заполнении.
	Ответить | Правка | Наверх | Cообщить модератору

	100. "Критическая уязвимость в  OpenSSL 1.1.0a"	–1 +/–
	Сообщение от angra (ok), 28-Сен-16, 02:15
	Массивы чаще всего используются так 'a[i]' или так 'a[i]=...', то есть читается или пишется один элемент. Даже если это делается в цикле, проходящем по всем элементам, то это ничего не меняет, проверка нужна на каждое обращение. Этого можно избежать в языках с конструкциями each/foreach, которые избавляют от явного индексирования, но в С их нет. mprotect это очень тяжелая операция, при этом требующая выравнивания данных по границам страниц. То есть лекарство в подавляющем большинстве случаев будет значительно хуже болезни.
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Критическая уязвимость в  OpenSSL 1.1.0a"	+/–
	Сообщение от Аноним84701 (?), 28-Сен-16, 14:33
	> Массивы чаще всего используются так 'a[i]' или так 'a[i]=...', то есть читается > или пишется один элемент. Даже если это делается в цикле, проходящем > по всем элементам, то это ничего не меняет, проверка нужна на > каждое обращение. Нет. Нужна проверка адреса на валидность перед циклом и ширины шага в самом цикле (последнее, если не заниматься  извращениями, вполне нормально проверяется компилятором). Если за один шаг цикла мы не можем перескочить "стража" .... то проверять каждое обращение конечно можно, но только "потому что гладиолус". > Этого можно избежать в языках с конструкциями each/foreach, которые > избавляют от явного индексирования, но в С их нет. Там таки обычно используются разновидности итераторов, которые или сами проверяют при каждой итерации (т.е. та же проверка, только в профиль) или, "тихой сапой", компилятором преобразуется в рановидность цикла со счетчиком. > mprotect это очень тяжелая операция, Никто не говорил, что mprotect так уж "легок", но strace ls strace time Вполне себе применяется для "разметки" границ стека или кучи.
	Ответить | Правка | Наверх | Cообщить модератору

	107. "Критическая уязвимость в  OpenSSL 1.1.0a"	–1 +/–
	Сообщение от angra (ok), 29-Сен-16, 01:34
	for (i=0;i<n;i++) { if (smth) {    i=m } a[i]=a[i-1]+a[i-2] b[i]=f(a[i]) } Вот тебе всего три из множества возможных вариантов, в которых твой наивный подход не работает.
	Ответить | Правка | Наверх | Cообщить модератору

	108. "Критическая уязвимость в  OpenSSL 1.1.0a"	+1 +/–
	Сообщение от Аноним84701 (?), 29-Сен-16, 03:35
	>  if (smth) { >    i=m >  } > Вот тебе всего три из множества возможных вариантов, в которых твой наивный > подход не работает. Ну-ну. 1. То, что вариант с smth != true => a[-1] + a[-2] => fail можно, совершенно внезапно, ловить еще на этапе компиляции. 2. m в реальном коде берется не из либастрала и вполне прослеживается компилятором — как минимум возможные значения (для всяких разных constant propagation, partial evaluation и всего такого). 3.  см. >> если не заниматься  извращениями >
	Ответить | Правка | Наверх | Cообщить модератору

	61. "Критическая уязвимость в  OpenSSL 1.1.0a"	+/–
	Сообщение от Аноним (-), 27-Сен-16, 10:23
	Хороший результат у Go. Даже в таком виде...
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

	65. "Критическая уязвимость в  OpenSSL 1.1.0a"	–1 +/–
	Сообщение от angra (ok), 27-Сен-16, 10:49
	Хороший, не спорю, но Изя то говорил про полное решение проблем с производительностью и памятью, не иначе как с помощью магии. На деле же видим типичный tradeoff и никакого волшебства.
	Ответить | Правка | Наверх | Cообщить модератору

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

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