В изменениях, внесённых в опубликованном (https://www.opennet.ru/opennews/art.shtml?num=45195) на прошлой неделе обновлении криптографической библиотеки OpenSSL 1.1.0a, выявлена (https://mta.openssl.org/pipermail/openssl-announce/2016-Sept... критическая уязвимость (CVE-2016-6309 (https://security-tracker.debian.org/tracker/CVE-2016-6309)), которая потенциально может привести к выполнению кода злоумышленника при обработке отправленных им пакетов. Всем пользователям ветки OpenSSL 1.1.0 рекомендуется срочно обновить OpenSSL до версии 1.1.0b (https://mta.openssl.org/pipermail/openssl-announce/2016-Sept.... Уязвимость выявлена сотрудниками Google при проведении fuzzing-тестирования нового выпуска инструментом honggfuzz (https://github.com/google/honggfuzz).
Проблема присутствует в выпуске OpenSSL 1.1.0a в коде устранения уязвимости CVE-2016-6307 и проявляется при получении сообщения, размером больше 16 Кб, в ситуации перераспределения и перемещения буфера, отведённого для поступающих сообщений. Суть ошибки в том, что после перераспределения памяти остаётся
висячий указатель (https://ru.wikipedia.org/wiki/%D0%92%D0%... на старое положение буфера и запись поступившего сообщения производится в ранее уже освобождённую область памяти. Наиболее вероятным результатом подобной записи будет крах, но разработчики не исключают нахождение векторов атаки, при которых возможно организовать выполнение кода атакующего.Интересно, что это не единственная ошибка, допущенная в прошлых выпусках. В представленном 22 сентября обновлении прошлой ветки (OpenSSL 1.0.2i) всплыла менее опасная уязвимость (CVE-2016-7052 (https://security-tracker.debian.org/tracker/CVE-2016-7052)), в результате которой при попытке использования CRLs возникал крах из-за разыменования нулевого указателя. Проблема устранена в выпуске OpenSSL 1.0.2j.
URL: https://mta.openssl.org/pipermail/openssl-announce/2016-Sept...
Новость: https://www.opennet.ru/opennews/art.shtml?num=45215
Почему в критически важных программах до сих пор используют указатели, а не проверяемые на этапе компиляции ссылки?
Потому что в критически важных программах (особенно в криптографии) критически важна скорость и низкое потребление памяти.
Как использование ссылок вместо указателей влияет на производительность?
Ты дурак? OpenSSL написан на С, откуда там ссылки?
Управляемый язык подразумевает виртуальную машину. Вот есть Java SSL, например, и что с этим делать вне JRE-мира?
C++ не является управляемым языком, однако ссылки там есть, вывод - надо писать на плюсах. А то на сишечке такой код нормально компилится и ждет своего часа.char a[256];
char *buf = a;
recv(hSocket, &buf, 256);
Вы так говорите, как будто в C++ нельзя сделать dangling reference.Есть, конечно, smart pointers, но это решает проблемы только локально и не всегда.
Rust?
Разве что теоретически - если вообще всё на нем вообще переписать, не используя unsafe-функции и raw pointers. На практике малореализуемо.Вот что на практике реализуемо - так это использовать инструменты статического и динамического анализа и придерживаться единого стиля. Большинство проблем с openssl - следствие исторически сложившейся запутанности его кода и отсутствия этих самых best practices: когда ответственность за выделение/освобождение памяти разнесена как попало, подобные ошибки просто неизбежны. Форки типа libressl как раз это и пытаются решить.
Настолько категорично переписывать всё и не обязательно – даже с unsafe-ом количество мест за которыми нужно следить сокращается многократно.Но всё же это всё мечты – переносить проект после такого длинного пути развития на plain c даже на плюсы уже целая эпопея (см. gcc).
> Настолько категорично переписывать всё и не обязательно – даже с unsafe-ом количество
> мест за которыми нужно следить сокращается многократно.
> Но всё же это всё мечты – переносить проект после такого длинного
> пути развития на plain c даже на плюсы уже целая эпопея
> (см. gcc).Многие проекты на C переносятся на плюсы переименованием файлов в .cpp, и добавлением префикса extern "C" для функций API
Может всё же не стоит путать пренос кода на другой язык с подключением этого же кода к коду на другом языке?
> Может всё же не стоит путать пренос кода на другой язык с
> подключением этого же кода к коду на другом языке?Тут некоторые аргументируют выбор языка в пользу С его производительностью, необходимой криптографическим алгоритмам. Программируя на С++ в стиле С мы не потеряем производительность и можем постепенно добавить элементы, которые есть только у С++. Теже ссылки вместо указателей, где это уместно
D?
Его главная проблема в том, что он метит скорее к высокоуровенным языкам, и в плане безопасности от тех же плюсов без использования GC не ушёл никуда.
> Его главная проблема в том, что он метит скорее к высокоуровенным языкам,высокоуровневые это C? он от сишника недалеко ушёл, и вынос некоторых вещей на уровень стиля программирования и проверку части ошибок на компилятор не сильно его приближает к жабам и окамлам. ИМХО то, что заказывали: "низкоуровневое" как C, чуть более безопасное, как C++. Это просто мои соображения, категорично утверждать не буду.
> и в плане безопасности от тех же плюсов без использования GC не ушёл никуда.
насколько я знаю использует подсчёт ссылок. уже хорошо.
>насколько я знаю использует подсчёт ссылок. уже хорошо.Нет, не использует. Ну, точнее есть самая наивная реализация самртпоинтеров в стандартной библиотеке как и в плюсах (при этом самое смешное что использовать их с отлкюченным GC или без рантайма не получится - эта реализация взаимодействует со сборщиком, чтобы тот корректно работал).
>высокоуровневые это C? он от сишника недалеко ушёлВот вообще ни разу - без сборщика течёт половина языка (те же билтиновые массивы, строки, замыкания и тд), аллокации на стёке в самом языке нет - есть в стандартной библиотекие, которая без GC не работает :)
> Нет, не использует. Ну, точнее есть самая наивная реализация самртпоинтеров в стандартной
> библиотеке как и в плюсах (при этом самое смешное что использовать
> их с отлкюченным GC или без рантайма не получится - эта
> реализация взаимодействует со сборщиком, чтобы тот корректно работал).по хабрам и D-пабликам ходит статья про обёртки для работы с отключеным GC, не оно? (про ровность такого решения пока не будем).
> Вот вообще ни разу - без сборщика течёт половина языка (те же
> билтиновые массивы, строки, замыкания и тд), аллокации на стёке в самом
> языке нет - есть в стандартной библиотекие, которая без GC не
> работает :)всё так плохо?
Бред. ""_ptr's (и smart_ptr) не имеют к GC никакого отношения. Все сводится к подсчету ссылок (ну, и определённые гарантии по жизненному циклу объектов).
Может стоит сначала открыть исходники и посмотреть прежде чем писать?
Или объяснить принцип работы GC и как память выделенная внутри объекта завёрнутого в смартпоинтер отслеживается сборщиком?
> Может стоит сначала открыть исходники и посмотреть прежде чем писать?Именно так. Вам стоит таки открыть исходники.
https://github.com/dlang/phobos/blob/master/std/typecons.d#L...
Ну...
А, так речь про D... Тогда все эти комментарии надо потереть.
> А, так речь про D... Тогда все эти комментарии надо потереть.Если какие-либо Ваши потеряли смысл после уточнения -- приведите их номера, пожалуйста.
Теперь D принято писать так:
:-DПотому что не взлетели.
Так зачем писать фигню, а потом её компилить и релизить?
> Потому что в критически важных программах (особенно в криптографии) критически важна скорость и низкое потребление памяти.Но в Go как-то решили обе эти проблемы. Или нет?
http://golang-book.ru/chapter-08-pointers.html
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
> http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...Результат предсказуем прежде всего из-за слабенького (по сравнению с GCC) оптимизатора в Go.
> Результат предсказуем прежде всего из-за слабенького (по сравнению с GCC) оптимизатора в Go.Если ты оптимизируешь проверки границ массивов - тормозить, конечно, перестанет, но тогда и проверок не будет :)
>> Результат предсказуем прежде всего из-за слабенького (по сравнению с GCC) оптимизатора в Go.
> Если ты оптимизируешь проверки границ массивов - тормозить, конечно, перестанет, но тогда
> и проверок не будет :)Вы еще расскажите, что проверки границ достаточно крупных массивов обязятельно должны тормозить "потому что гладиолус" ;)
Нет, не гладиолус, а по причине того, что проверка выполняется при каждой операции, так что абсолютно фиолетово какой там размер массива.
> Нет, не гладиолус, а по причине того, что проверка выполняется при каждой
> операции, так что абсолютно фиолетово какой там размер массива.При последовательном обходе, копировании в/из и т.д:
mprotect(..., PROT_NONE) на страничку памяти (или несколько, зависит от размера элементов) после массива — и ваши массивы будут мягкими и шелковистыми! Да и проверка (одна) в таком случае нужна только перед началом сего действа и только в том случае, если собираемся проходить не с нулевого элемента.Просто "стOит" это дело одну-две дополнительные страницы памяти (т.к. "валидная" длина массива будет кратной размеру страницы памяти), и не спасет при произвольном доступе/заполнении.
Массивы чаще всего используются так 'a[i]' или так 'a[i]=...', то есть читается или пишется один элемент. Даже если это делается в цикле, проходящем по всем элементам, то это ничего не меняет, проверка нужна на каждое обращение. Этого можно избежать в языках с конструкциями each/foreach, которые избавляют от явного индексирования, но в С их нет.mprotect это очень тяжелая операция, при этом требующая выравнивания данных по границам страниц. То есть лекарство в подавляющем большинстве случаев будет значительно хуже болезни.
> Массивы чаще всего используются так 'a[i]' или так 'a[i]=...', то есть читается
> или пишется один элемент. Даже если это делается в цикле, проходящем
> по всем элементам, то это ничего не меняет, проверка нужна на
> каждое обращение.Нет. Нужна проверка адреса на валидность перед циклом и ширины шага в самом цикле (последнее, если не заниматься извращениями, вполне нормально проверяется компилятором).
Если за один шаг цикла мы не можем перескочить "стража" .... то проверять каждое обращение конечно можно, но только "потому что гладиолус".> Этого можно избежать в языках с конструкциями each/foreach, которые
> избавляют от явного индексирования, но в С их нет.Там таки обычно используются разновидности итераторов, которые или сами проверяют при каждой итерации (т.е. та же проверка, только в профиль) или, "тихой сапой", компилятором преобразуется в рановидность цикла со счетчиком.
> mprotect это очень тяжелая операция,
Никто не говорил, что mprotect так уж "легок", но
strace ls
strace time
Вполне себе применяется для "разметки" границ стека или кучи.
for (i=0;i<n;i++) {
if (smth) {
i=m
}
a[i]=a[i-1]+a[i-2]
b[i]=f(a[i])
}Вот тебе всего три из множества возможных вариантов, в которых твой наивный подход не работает.
> if (smth) {
> i=m
> }
> Вот тебе всего три из множества возможных вариантов, в которых твой наивный
> подход не работает.Ну-ну.
1. То, что вариант с smth != true => a[-1] + a[-2] => fail
можно, совершенно внезапно, ловить еще на этапе компиляции.
2. m в реальном коде берется не из либастрала и вполне прослеживается компилятором — как минимум возможные значения (для всяких разных constant propagation, partial evaluation и всего такого).
3. см.
>> если не заниматься извращениями
>
Хороший результат у Go. Даже в таком виде...
Хороший, не спорю, но Изя то говорил про полное решение проблем с производительностью и памятью, не иначе как с помощью магии. На деле же видим типичный tradeoff и никакого волшебства.
Потому что C - это религия.
> Потому что C - это религия.Никогда не считал себя религиозным фанатиком, но ты мне не нравишься. [ушёл собирать хворост для костра]
> Почему в критически важных программах до сих пор используют указатели, а не
> проверяемые на этапе компиляции ссылки?OpenSSL написан на сишечке, там ссылок нет
> а не проверяемые на этапе компиляции ссылки?Проверяемые кем? Висячие ссылки не менее реальны, чем висячие указатели. И потом, работать ссылками с сырым буфером - это отдельное извращение.
Он даже в джаве теоретик, что перед ним бисер метать.
Потому, что ссылка, указатель и адрес в памяти есть тождественные синонимы одного и того же. Ваш КЭП. :)А то, что в некоторых случаях предпочитают не выстраивать системы на постоянных утечках памяти и непредсказуемом времени поведения, так это бывает. Пережитки старой школы программирования. :)
Потому что ссылки это C++, а тупoрылые ретрограды которые пишут OpenSSL, и, кстати, большую часть FreeBSD, до сих пор используют plain C - устаревший, небезопасный и кoрявый язычoк.
> Потому что ссылки это C++, а тупoрылые ретрограды которые пишут OpenSSLКак же всё-таки безнадёжно выглядят вот такие организмы, почему-то не берущие восхваляемый инструмент в руки и не показывающие, как было надо сделать сразу.
Особенно забавно, когда вляпываются просто в другие ошибки и начинают поносить то, что вчера восхваляли -- мол, как же, подгузники не подали, оказывается.
Эх.
да куеватуча бест практис по секурному кодингу на сях, видать никто не читает, практики статического анализа у сишников нет, есть тока мантра дбг корки и всё, бага - да фиг с ней, корку под дбг и всё решено.пс: а по сути большинство возмущений только из-за того, что но вый баг - это последствие фикса старого, и не менее критичного в итоге. вот весь фейспалм, не нужно ругать ЯП. 40 с лишнем лет языку и всегда он был такой - пора бы привыкнуть.
есть еще копипейст и очепятки, причём во всех языках.
> да куеватуча бест практис по секурному кодингу на сях, видать никто не читаетА можно ссылочку?
Гугл помощь, или примеру на cert.org посмотри, там есть книжка по secure coding
> Как же всё-таки безнадёжно выглядят вот такие организмы, почему-то не берущие восхваляемый инструмент в руки и не показывающие, как было надо сделать сразу.Так я на C++ пишу. И что-то дырок в моих проектах каждый день по десятку не находят.
> Особенно забавно, когда вляпываются просто в другие ошибки и начинают поносить то, что вчера восхваляли -- мол, как же, подгузники не подали, оказывается.
Глупый ты, миша.
>> Как же всё-таки безнадёжно выглядят вот такие организмы, почему-то не берущие
>> восхваляемый инструмент в руки и не показывающие, как было надо сделать сразу.
> Так я на C++ пишу. И что-то дырок в моих проектах каждый день по десятку не находят.Джо, но где же Ваша реализация SSL-библиотеки?
>> Особенно забавно, когда вляпываются просто в другие ошибки и начинают поносить то,
>> что вчера восхваляли -- мол, как же, подгузники не подали, оказывается.
> Глупый ты, миша.Может быть. Только что-то уже повидавший. В том числе и такое.
> тупoрылые ретроградыА уж генетический код то какой устаревший.... Все эти ДНК,РНК и т.д. УЖАСТЬ КАКОЕ СТАРЬЁ!
Фак.
Ну сколько можно так косячить...
Если не будет постоянных багов - программисты останутся без работы. Это как с полицией: если однажды преступность будет полностью побеждена, все полицейские будут уволены за ненадобностью. Си - это программистский хлеб в плане багообразования.
> все полицейские будут уволены за ненадобностьюВы так говорите, будто это что-то плохое.:)
> Если не будет постоянных багов - программисты останутся без работы. Это как
> с полицией: если однажды преступность будет полностью побеждена, все полицейские будут
> уволены за ненадобностью. Си - это программистский хлеб в плане багообразования.ага и касперский пишет вирусы )))
> ага и касперский не пишет вирусы )))fix
> Если не будет постоянных багов - программисты останутся без работы.Создавать новые программы для тебя не вариант? Предпочитаешь паразитировать на исправлении и добавлении багов в одну и ту же?
> Это как с полицией: если однажды преступность будет полностью побеждена, все полицейские будут уволены за ненадобностью.
Предотвращать появление новой преступности будет ненужно? Ты, когда дождик кончается, зонтик сразу выкидываешь за ненадобностью?
> Создавать новые программы для тебя не вариант?Для меня - вполне себе вариант. Я говорил о сишниках и об их деятельности по многодесятилетнему созданию и исправлению одних и тех же багов. Топчутся на одном месте, зато зарплата идет. И видимость работы как бы есть. Вон, сколько багов закрыли. Ух! А потом закроют еще больше, внося каждый раз два новых бага на место одного закрытого.
> Ты, когда дождик кончается, зонтик сразу выкидываешь за ненадобностью?
Да, я увольняю зонт, запихивая его с глаз долой куда подальше. Если начнется дождь (а моя аналогия была все-таки про полное уничтожение преступников как класса) -- я найму зонт снова, взяв его оттуда, куда запихнул до этого. Твое мышление -- это уничтожение частных случаев, в лоб, ошибка за ошибкой. А мое - уничтожение целого класса, чтобы понятие stack overflow осталось где-то в прошлом, на страницах истории, как пережиток древних языков.
> Да, я увольняю зонт, запихивая его с глаз долой куда подальше.Как для маковода - вполне предсказуемые действия.
> Я говорил о сишниках и об их деятельности по многодесятилетнему созданию и исправлению одних и тех же багов.
> Топчутся на одном месте, зато зарплата идет. И видимость работы как бы есть.То ли дело Java программисты.
Только вперёд! Если класс, то только с новой функциональностью!
Без всякой зарплаты! За идею!
К чему это или о чем?
> То ли дело Java программисты.
> Только вперёд! Если класс, то NullPointerException
> Без всякой зарплаты! За идею!Не удержался.
То есть с точки зрения эльфа баги есть только в Сишных программах. На php, где нет богомерзких указателей, пишут исключительно безбажные программы?Зонт нельзя уволить, это не человек, его можно выкинуть или положить на место. Дай догадаюсь, ты, как положено эльфу, наивен во всем и считаешь, что можно сначала разогнать, а потом с легкостью нанять заново полицию и она будет работать с той же эффективностью.
> На php, где нет богомерзких указателей, пишут исключительно безбажные программы?На пыхе баги в основном касаются бизнес-логики. А на сишечке -- бизнес-логика + стандартные вечные stack overflow. Пыхеры проявляют гораздо бОльшую обучаемость, чем сишники; например, в пыхе частенько случались sql-инъекции. Что сделали пыхеры? Стали обращаться к бд посредством безопасных query-builder-ов или подставляя значения в шаблон. Уничтожили баги как класс. Сишники же просто в лоб решают свою хроническую болезнь и не собираются отказываться от ручного управления памятью. Ну тут уж можно сказать только одно: каждый доказывает свою нужность так, как может. Сишники например - путем постоянной генерации и исправления однотипных багов.
> можно сначала разогнать, а потом с легкостью нанять заново полицию и она будет работать с той же эффективностью
Конечно можно. Голод не тетка. Эффективность правда будет уже не той. Она будет повыше. Потому что полицейские теперь будут знать, что раз их уже увольняли - в этот раз им понадобится доказывать свою нужность с удвоенной силой. И тогда совершенно точно можно не ожидать исстребления преступности как класса.
>> На php, где нет богомерзких указателей, пишут исключительно безбажные программы?
> На пыхе баги в основном касаются бизнес-логики.И много sql injections или csrf бывает в бузинес-логике всяких joomla с phpmyadmin?
> А на сишечке -- бизнес-логика + стандартные вечные stack overflow.
И много Вы лично видали именно bl на Це?
> Пыхеры проявляют гораздо бОльшую обучаемость, чем сишники; например, в пыхе частенько
> случались sql-инъекции. Что сделали пыхеры? Стали обращаться к бд посредством
> безопасных query-builder-ов или подставляя значения в шаблон. Уничтожили баги как класс.Что, серьёзно уничтожили?
Сдаётся мне, у Вас просто какая-то идея фикс насчёт геноцида, при этом причину ошибок понять не в состоянии -- возможно, по той простой причине, что свои собственные ошибки анализировать не склонны, как и персонажи http://egorfine.com/ru/articles/worse-than-failure/
> Сишники же просто в лоб решают свою хроническую болезнь и не собираются отказываться
> от ручного управления памятью.Сишники работают бензопилой. Это инструмент такой, со своими плюсами и минусами. Вы пытаетесь предложить двуручную пилу, которая, конечно, намного безопасней. Особенно если ей зубы ещё позагибать.
> Ну тут уж можно сказать только одно: каждый доказывает свою нужность так, как может.
Отлично иллюстрируете своё утверждение.
> Сишники например - путем постоянной генерации и исправления однотипных багов.
Не то что php-шники? (среди которых профи есть, но за теми подобных высказываний не припоминаю)
> Конечно можно. Голод не тетка. Эффективность правда будет уже не той.
> Она будет повыше. Потому что полицейские теперь будут знать, что раз их
> уже увольняли - в этот раз им понадобится доказывать свою нужность
> с удвоенной силой. И тогда совершенно точно можно не ожидать исстребления
> преступности как класса.А здесь мы видим такие же крупные (и однотипные) проблемы с логикой и способностью воспринимать доводы прямым текстом, не то что намёки.
Вас если выгнать -- за дело или просто так -- в следующий раз в ту же лавку будете рваться с удвоенной силой? Не, серьёзно?
А если так поразгонять дворников, то листья перестанут падать?..
PS: буду крайне рад ошибиться в оценочных суждениях, разумеется.
> при этом причину ошибок понять не в состоянииПричина ошибок что с sql-инъекциями, что со stack overflow, одна и та же: невнимательность. Только пыхеры признали невнимательность как свою проблему и одолели ее. А сишники продолжают считать себя сверх-людьми, умеющими вовремя распознавать ситуации, когда требуется освободить память. Не зря в библии гордыня считается одним из смертных грехов. (И нет, я не религиозник.)
> Вы пытаетесь предложить двуручную пилу, которая, конечно, намного безопасней
Нет, я предлагаю изолировать бензопилу от людей. Если продолжать аналогию, то бензопилой орудовали бы роботы, которые в том числе автоматически занимались бы сборкой мусора. А людям оставалось бы лишь отдавать им сырье и возвращаться за готовым результатом.
> если так поразгонять дворников, то листья перестанут падать?
Если однажды случится такое, что листья принципиально перестанут падать, то сборщиков листьев придется уволить. Ты здесь слегка попутал причину и следствие.
>> при этом причину ошибок понять не в состоянии
> Причина ошибок что с sql-инъекциями, что со stack overflow,
> одна и та же: невнимательность.Ура!
> Только пыхеры признали невнимательность как свою проблему и одолели ее.
Ну вот, опять сказки пошли...
> Нет, я предлагаю изолировать бензопилу от людей. Если продолжать аналогию,
> то бензопилой орудовали бы роботы, которые в том числе автоматически занимались
> бы сборкой мусора. А людям оставалось бы лишь отдавать им сырье и возвращаться
> за готовым результатом.Да-да, неломающиеся и неглючащие роботы, которые берутся из ниоткуда и деваются в никуда. Языки программирования, где достаточно нажать Кнопку. И всё такое прочее.
>> если так поразгонять дворников, то листья перестанут падать?
> Если однажды случится такое, что листья принципиально перестанут падать,
> то сборщиков листьев придется уволить. Ты здесь слегка попутал причину и следствие.Я намеренно "запряг телегу впереди лошади" в вопросе о том, может ли преступность пропасть как класс (sic!) в зависимости от эффективности противодействия таковой. Ну, вдруг заметите, где у Вас этсамая путаница причин, следствий и отсутствия таковых.
> Ну вот, опять сказки пошли...Повсеместное использование query-build-еров и подстановок - сказка? Отнюдь. Пыхеры просто сделали так, чтобы их невнимательность больше не угрожала безопасности. Сишники не идут их путем по причинам, которые я изложил выше.
> неломающиеся и неглючащие роботы
Если робот поломался - то поломался он для всех сразу. Проблема изолирована в одном месте - в помещении, где орудуют роботы. Следовательно, если пофиксить робота - пофиксятся сразу все баги сразу у всех клиентов робота. И не надо будет сначала патчить один проект, потом однотипно патчить другой проект и т. д.
> может ли преступность пропасть как класс (sic!) в зависимости от эффективности противодействия таковой
Разумеется может. Просто полиция - это наиболее корявый способ ее устранения. Гораздо более эффективными явили себя частные страховые агенства. Если полицейский, для получения дополнительных звездочек, __нуждается__ в существовании преступника, которого он бы поймал, то страховые агенства нуждаются в их отсутствии, так как преступники генерируют им страховые случаи.
>> Ну вот, опять сказки пошли...
> Повсеместное использование query-build-еров и подстановок - сказка? Отнюдь.Разница между распространением и гарантией понятна? Так-то и сишные функции работы со строками применяются (если оставаться в рамках предложенного сравнения).
>> неломающиеся и неглючащие роботы
> Если робот поломался - то поломался он для всех сразу.Как правило, всего лишь для пользователей экземпляра.
> Следовательно, если пофиксить робота - пофиксятся сразу все баги сразу у всех
> клиентов робота.Зависит от конкретики "пофиксить" и "все баги" как минимум. Доводилось видать людей, необузданный оптимизм которых в подобных формулировках приводил к большим проблемам...
Но речь вообще-то была о накладных расходах при эксплуатации более сложных систем. Которые могут быть более эффективными, но вовсе не обязательно.
>> может ли преступность пропасть как класс (sic!) в зависимости
>> от эффективности противодействия таковой
> Разумеется может.Хотя бы один известный практический пример воспоследует?
> Гораздо более эффективными явили себя частные страховые агенства.
Которые, разумеется, честны и неполживы, а обнуление страховых случаев производят пассами руками.
Ох уж эти сказочники с идеями, которые они даже мысленным экспериментом как следует не проверяли... да ещё и не понимающие, что те же страховщики -- это по сути ещё один вариант мафии, который кровно заинтересован в давлении на максимально широкий круг объектов для выколачивания из них потока средств; и что давление на практике бывает от "цивилизованного" законодательного до банального "не застраховано -- случайно сгорело".
Часом не утопий обчитались?
> в пыхе частенько случались sql-инъекции. Что сделали пыхеры? Стали
> обращаться к бд посредством безопасных query-builder-ов или подставляя значения в шаблон.Слишком жЫрно.
Те же prepared statements появились в *рен-знает-каком году.
В пыхе встроенная поддержка как минимум с 2006 года ... но пыховцы о ней слышали:
https://www.cvedetails.com/vulnerability-list/opsqli-1/sql-i...
> Total number of vulnerabilities : 6362что-то хвалененая обучаемость не спешит проявлятся )
> Конечно можно. Голод не тетка. Эффективность правда будет уже не той. Она будет повыше. Потому что полицейские теперь будут знать, что раз их уже увольняли - в этот раз им понадобится доказывать свою нужность с удвоенной силой. И тогда совершенно точно можно не ожидать исстребления преступности как класса.Они уже умные и заранее работают с ДОСТАТОЧНОЙ эффективностью. Работа как видите у них не кончается и увольнять никого не нужно
> Они уже умные и заранее работают с ДОСТАТОЧНОЙ эффективностью.
> Работа как видите у них не кончается и увольнять никого не нужноРабота полицейских в плане противодействия преступности могла бы закончиться, если бы люди стали безгрешными, причём все. Этого не предвидится, скорее идёт обратный процесс (в том числе и судя по себе).
Ну и листья всё так же падают...
В моём районе есть кирпич и водители постоянно под него едут, и полицейские приезжают и штрафуют с достаточной периодичностью чтобы водители не слишком боялись. Можно было бы повесить камеру и начислять штрафы автоматом, но тогда поток нарушений закончился бы и камера была бы не нужна. И так не только в моём примере.Программируя на Си не ошибаться невозможно, в силу несовершенства человеческой природы.
> Можно было бы повесить камеру и начислять штрафы автоматом, но
> тогда поток нарушений закончился бы и камера была бы не нужна.Выясните, кто занимается выставлением дорожных знаков (кажется, в моём аналогичном случае пришлось через дорожную службу выйти на районную администрацию, но это было ещё в Киеве со знаком "движение направо", влепленным напротив разрыва в двойной под предлогом якобы плохой видимости), и сообщите о проблеме -- если кирпич там объективно лишний, пущай снимают, а если нужен -- укрепляют.
> не ошибаться невозможно в силу несовершенства человеческой природы.
В целом да.
> Программируя на Си не ошибаться невозможно
В частности же известны люди вроде djb, которые предлагали деньги за найденные ошибки в своём сишном коде. А слова вроде "невозможно" или "никогда" -- они тяжёлые...
Станислав Лем. Звездные дневники Ийона Тихого. Путешествие двадцать четвертое
>> если бы люди стали безгрешными, причём все
> Станислав Лем. Звездные дневники Ийона Тихого. Путешествие двадцать четвертоеТам не люди (что до, что после "гармонизации").
PS: но всяко спасибо :)
> Пыхеры проявляют гораздо бОльшую обучаемость, чем сишники; например, в пыхе частенько случались sql-инъекции. Что сделали пыхеры? Стали обращаться к бд посредством безопасных query-builder-ов или подставляя значения в шаблон. Уничтожили баги как класс.Спасибо, посмеялся. Обучаемость основной массы пыхеров это просто пять с плюсом, особенно с учетом "подставляя значения в шаблон", ведь именно так и получаются sql инъекции. Ты бы хоть про prepared statement почитал, которые есть в пыхе уже с десяток лет, но инъекции никуда не деваются, так как особо одаренные все еще подставляют значения в шаблон.
> Конечно можно. Голод не тетка. Эффективность правда будет уже не той. Она
> будет повыше. Потому что полицейские теперь будут знать, что раз их
> уже увольняли - в этот раз им понадобится доказывать свою нужность
> с удвоенной силой.Знаешь я тебя даже понимаю, мне ведь тоже приходили подобные "глубокие" мысли лет в десять. Мы не рождаемся с богатым жизненным опытом и пониманием устройства общества, всё приходит со временем. Ничего, повзрослеешь, закончишь школу, начнешь работать и если не дурак и способен учится, то сам потом посмеешься со своей детской наивности.
> stack overflowМожет случиться в любой программе на любом языке, от незнания\криворукости\усталости программера. Просто в C++\Java она выкинет эксепшн, только и всего.
> Фак.
> Ну сколько можно так косячить...В следующих сериях нашего сериальчика Вы также увидите рассказы клоунов нашего секьюрить сыркуса про то, что так было и так будет есть. Также приглашённая звезда развенчает весь сыркус и сделает пару победных кругов по манежу. Следите за анонсами!
https://outflux.net/slides/2016/lss/kspp.pdf
http://kernsec.org/files/lss2015/giant-bags-of-mostly-water.pdf
> Проблема присутствует в выпуске OpenSSL 1.1.0a в коде устранения уязвимости CVE-2016-6307Всем разрабам срочно нобелевскую премию за успешные попытки сделать IT мир не очень скучным.
> В RHEL/CentOS, Fedora и SUSE проблема не проявляется.Кто там в соседней теме про "ха-ха" писал? ;)
>> В RHEL/CentOS, Fedora и SUSE проблема не проявляется.
> Кто там в соседней теме про "ха-ха" писал? ;)Да тут и https://www.opennet.ru/openforum/vsluhforumID3/109194.html#3 спрашивали...
PS: а двойная ирония ситуации да, великолепна :)
> PS: а двойная ирония ситуации да, великолепна :)Ну а куда без неё? :)
Еще один факт, доказывающий что в OpenSSL некомпетентные люди пилят.
Вообще OpenSSL через разные утилиты прогонят и проверяют через профайлеры?Мое предпочтение ИМХО LibreSSL и был бы рад когда FreeBSD перейдет на него по умолчанию как сделали это DragonFlyBSD.
> Еще один факт, доказывающий что в OpenSSL некомпетентные люди пилят.
> Вообще OpenSSL через разные утилиты прогонят и проверяют через профайлеры?
> Мое предпочтение ИМХО LibreSSL и был бы рад когда FreeBSD перейдет на
> него по умолчанию как сделали это DragonFlyBSD.с ситемой то будет поставляться либра, а вот половина софта из портов (пакетов) юзают именно openssl, не отвяжешся так просто.
> с ситемой то будет поставляться либра, а вот половина софта из портов
> (пакетов) юзают именно openssl, не отвяжешся так просто.согласен, но со временем и софт с портов начнет внедрять поддержку LibreSSL...
половина? в OpenBSD я недавно насчитал 6 штук. или 5. причём половина из них - из-за неторопливости маинтайнеров, как мне кажется
Void Linux как раз на либре. :)
Шикарная формулировка: "This security update addresses issues that were caused by patches included in our previous security update" - Данное обновление безопасности исправляет проблемы, вызванные патчами, включёнными в наше предыдущее обновление безопасности.
> Данное обновление безопасности исправляет проблемы, вызванные патчами, включёнными в наше предыдущее обновление безопасности.ну классика - "В релизе X было исправленно Y ошибок". Просто о том, сколько при этом было внесено новых обычно умалчивают ;)
Нужен еще один аудит, а потом заставить всех опеннетчиков читать код (или делать вид). Так победим.
Аноним - не читатель, аноним - писатель. :-)
> Аноним - не читатель, аноним - писатель. :-)Пусть эти, как их... зарегистрированные читют.
Буратино тоже использует OpenSSL?
> Буратино тоже использует OpenSSL?Интересно, с чего вдруг такое предположение, если ББ сидит на OpenBSD, где LibreSSL по определению в базе?
уже выпустили, за примерное поведениесва-бо-ду бу-ра-ти-нам!
Снова, опять.