не в опенсорс об этом баге может быть вообще никогда не узнали бы или узнали бы спустя лет десять
А, собственно, кто сказал, что (в общем случае) это плохо? Ведь, если блюмберг нам не врет и АНБ действительно знало о heartbleed и успешно эксплуатировало ее в течении нескольких лет (http://www.theverge.com/2014/4/11/5605444/the-nsa-has-exploited-heartbleed-bug-for-years-bloomberg-reports), то сразу возникают настолько же неудобные для сторонников защищенности опенсорса, насколько и риторические вопросы: а откуда АНБ о ней узнало и насколько вероятно то, что такая же участь постигла бы какой-либо аналогичный продукт с закрытым исходным кодом?
Ну и обобщая: благодаря чему у АНБ не будет затруднений с получением 0-day для в т.ч. открытых проектов, которые им давеча официально разрешил использовать их верховный афроамериканский вождь (http://www.securitylab.ru/news/451522.php)? Есть желающие выступить на стороне опенсорса и обеспечить баланс светлых и темных сил, уводя из под носа АНБ все вкусные уязвимости? Или я не там спрашиваю и те пресловутые миллионы пар глаз сосредоточены где-то в другом месте, а не на форумах разработчиков?
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>а откуда АНБ о ней узнало и насколько вероятно то, что такая же участь постигла бы какой-либо аналогичный продукт с закрытым исходным кодом?
Насколько я помню, уже довольно давно поднимался вопрос о возможности внедрения бэкдоров в опенсорс. И все красноглазики в один голос доказывали, что этого не может быть, потому что не может быть никогда.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Ну и обобщая: благодаря чему у АНБ не будет затруднений с получением 0-day для в т.ч. открытых проектов, которые им давеча официально разрешил использовать их верховный афроамериканский вождь (http://www.securitylab.ru/news/451522.php)? Есть желающие выступить на стороне опенсорса и обеспечить баланс светлых и темных сил, уводя из под носа АНБ все вкусные уязвимости?
Да. Исходники Винды доступны для NSA. Ты думаешь, что они не знают про уязвимости там?
Здравствуйте, kleng, Вы писали:
C>>Да. Исходники Винды доступны для NSA. Ты думаешь, что они не знают про уязвимости там? K>Исходники OpenSSL доступны тому же NSA, а так же широчайшему кругу лиц различной степени злонамеренности.
Это значит, что дырки всплывут, скорее всего, через whitehat-компании.
Здравствуйте, kleng, Вы писали:
C>>Это значит, что дырки всплывут, скорее всего, через whitehat-компании. K>Когда-нибудь, после неопределенного периода использования by black hats.
Возможно. Но точно так же black hats могут найти дырки в бинарных компонентах или в стыреных закрытых исходниках. Причём у них будет намного меньше мотивации эти дырки раскрывать публично.
Здравствуйте, kleng, Вы писали:
C>>Возможно. Но точно так же black hats могут найти дырки в бинарных компонентах или в стыреных закрытых исходниках. K>Точно так же, как и white hats.
То есть?
Здравствуйте, kochetkov.vladimir, Вы писали:
KV> сразу возникают настолько же неудобные для сторонников защищенности опенсорса,
я вас умоляю. откомпилируйте старого лиса новым компилятором. ошибки переполнения обнаруживаются как на стадии компиляци, так и в райнайте на стадии иницилизации (то есть при запуске). причем эти версии все еще используются в различных дистрах линуха. таким образом, мы точно знаем где дыра (компилятор пальцем показал) и знаем какие дистры какого лиса используют. так же нам известно, что далеко не все пользователи линуха в обязательном порядке скачивают самые свежие версии дистров и уж точно далеко не все обновляют лиса, а старые версии лиса вообще никак не обновляются.
самое интересное, что никто толком не знает кому бить яйца. разработчики лиса поддерживают _некоторые_ ветки старых версий, поскольку они все еще в строю, но делают это в состоянии гробового молчания. в принципе, можно сходить на репы и посмотреть на даты последних правок, что как бы намекает на. но официально старые версии не поддерживаются и вам рекомендуют пользоваться версиями первой (в крайнем случае второй) свежести. но как ими пользоваться, если на старом дистре для этого нужно обновлять 100500 библиотек и не факт, что ранее установленные пакеты не отвалятся и ничего не поломается?
если сходить на cvedetails, то можно обнаружить, что дыр в опенсурсе примерно столько же сколько и в закрытом софте. кстати, о закрытом софте. как вам нравится дыра в ms office с рекомендацией ms отключить поддержку rtf для предотвращения атаки на время пока ms работает над патчем? они бы еще сказали отправить всех в неоплачиваемый отпуск и не включать компьютер.
а как вам нравится атака на видеокамеры (arm, linux), которых добрые хакеры напрягли майнингом битконов, используя пароль по умолчанию, который далеко не все пользователи этих самых камер поменяли? это не проблема опенсурса, но жертвам атаки от этого не легче.
ЗЫ. сегодня получил от банка письмо. в письме говориться, что если у вас пропали деньги со счета, то их возместит страховая. до $100k вернут все, что было. а кто хранил больше $100k в одном банке... shit happens. впрочем, этим сейчас занимается FBI и US Secret Service, так что шансы на возврат средств, превышающих $100k, все-таки есть. но по имеющимся у меня данным, среднестатистические потери не превышают сотни баксов на рыло. банки подсуетились и все подозрительные транзакции на значительные суммы проводили только после звонка клиенту войсом.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>А, собственно, кто сказал, что (в общем случае) это плохо? Ведь, если блюмберг нам не врет и АНБ действительно знало о heartbleed и успешно эксплуатировало ее в течении нескольких лет (http://www.theverge.com/2014/4/11/5605444/the-nsa-has-exploited-heartbleed-bug-for-years-bloomberg-reports), то сразу возникают настолько же неудобные для сторонников защищенности опенсорса, насколько и риторические вопросы: а откуда АНБ о ней узнало и насколько вероятно то, что такая же участь постигла бы какой-либо аналогичный продукт с закрытым исходным кодом?
Если вспомнить, какие люди работают в подобных структурах, то наоборот становится удивительным, что они нашли и эксплуатировали эту дырку в опенсурсе. Более логичное и естественное их поведение пригласить директора конторы некоего проприетарного софта к себе в контору (или самим в гости зайти) и попросить сделать для них бэкдуру в их софте.
Здравствуйте, Vzhyk, Вы писали:
V>Если вспомнить, какие люди работают в подобных структурах, то наоборот становится удивительным, что они нашли и эксплуатировали эту дырку в опенсурсе. Более логичное и естественное их поведение пригласить директора конторы некоего проприетарного софта к себе в контору (или самим в гости зайти) и попросить сделать для них бэкдуру в их софте.
Здравствуйте, a_g_99, Вы писали:
__>Вы штаты с белорусь перепутали.
Хочешь сказать, что в РБ земляне живут, а в штатах марсиане? Люди за земном шарике ну очень похожи, а если еще и деятельность одинаковая, то как "близнецы-братья".
Генерал российской армии будет больше похож на генерала американской армии, чем на российского программиста, тоже и к сотрудникам спецслужб относится.
Здравствуйте, Vzhyk, Вы писали:
V>Если вспомнить, какие люди работают в подобных структурах, то наоборот становится удивительным, что они нашли и эксплуатировали эту дырку в опенсурсе. Более логичное и естественное их поведение пригласить директора конторы некоего проприетарного софта к себе в контору (или самим в гости зайти) и попросить сделать для них бэкдуру в их софте.
не в опенсорс об этом баге может быть вообще никогда не узнали бы или узнали бы спустя лет десять
KV>А, собственно, кто сказал, что (в общем случае) это плохо?
Чтобы оценивать, надо знать как оценивать. Что такое хорошо и что такое плохо?
С точки зрения криптоанализа взломщик секрета может (и должен) знать все кроме секрета. В другом виде задача взлома не имеет смысла. Поэтому опенсорс чуть ближе к правильной постановке задачи, тем самым можно более точно оценить защищенность.
Кстати все эти конкурсы по взлому неизвестной закрытой программы, сервиса, трафика и тп выглядят как рекламная акция и не более.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Вообще-то, у АНБ один из крупнейших исследовательских центров (http://www.nsa.gov/research/ia_research/index.shtml). В частности SELinux (привет использующим ядра с ним дистрибутивам linux, android 4.3+ и т.д.) является их разработкой (http://www.nsa.gov/research/selinux/). Да и активное участие АНБ в проекте NVD (https://nvd.nist.gov/) как бы намекает.
Молодцы они. Круты. Ну и ты сам привел факт, что они сами же и являются разработчиками одного из Линухов и грешно им не делать бэкдуры. Но, я писал немного о другом, о том, что никто им не может помешать предложить конторе самой сделать бэкдур в проприетарном софте для них.
Остался только один нюанс. В опенсурсном есть шанс, что кто-то когда-то засунет нос и поднимет скандал, а вот для проприетарного и такого шанса нет.
не в опенсорс об этом баге может быть вообще никогда не узнали бы или узнали бы спустя лет десять
KV>А, собственно, кто сказал, что (в общем случае) это плохо? Ведь, если блюмберг нам не врет и АНБ действительно знало о heartbleed и успешно эксплуатировало ее в течении нескольких лет (http://www.theverge.com/2014/4/11/5605444/the-nsa-has-exploited-heartbleed-bug-for-years-bloomberg-reports), то сразу возникают настолько же неудобные для сторонников защищенности опенсорса, насколько и риторические вопросы: а откуда АНБ о ней узнало и насколько вероятно то, что такая же участь постигла бы какой-либо аналогичный продукт с закрытым исходным кодом?
KV>Ну и обобщая: благодаря чему у АНБ не будет затруднений с получением 0-day для в т.ч. открытых проектов, которые им давеча официально разрешил использовать их верховный афроамериканский вождь (http://www.securitylab.ru/news/451522.php)? Есть желающие выступить на стороне опенсорса и обеспечить баланс светлых и темных сил, уводя из под носа АНБ все вкусные уязвимости? Или я не там спрашиваю и те пресловутые миллионы пар глаз сосредоточены где-то в другом месте, а не на форумах разработчиков?
АНБ само заинтересовано в секьюрной ОС для своих компьютеров. Или у них только коммерческий Юникс?
За всеми не уследишь. Следят выборочно за ключевыми персонами. Хорошо иметь лазейку в ОС такой персоны. Или проще воспользоваться магией и прочитать секрет прямо в мыслях подозреваемого?
Здравствуйте, Vzhyk, Вы писали:
V>Остался только один нюанс. В опенсурсном есть шанс, что кто-то когда-то засунет нос и поднимет скандал, а вот для проприетарного и такого шанса нет.
Почему же. Если NSA внедряет бэкдор в опенсорс, то об этом никто кроме NSA знать не обязан.
Если же они вставляют бэкдор в проприетарный софт, то об этом обязаны знать определённые люди в проприетарной компании. То есть знания о бэкдоре уже не под контролем NSA, и leak может выйти в любой момент. То есть количество людей, которые могут поднять скандал, возможно даже выше, чем на практике в опенсоурсе.
Здравствуйте, Cyberax, Вы писали:
C>Да. Исходники Винды доступны для NSA.
Если ты про их ранние снапшоты на момент сертификации каждой из сертифицированных версий — да. Если ты про актуальная версию всея виндов — пруф, пожалуйста.
C>Ты думаешь, что они не знают про уязвимости там?
Я так и думал, что тема их осведомленности об уязвимостях в закрытых продуктах, исходными кодами которых они не обладают, вопросов не вызовет
Здравствуйте, RiNSpy, Вы писали:
RNS>Если же они вставляют бэкдор в проприетарный софт, то об этом обязаны знать определённые люди в проприетарной компании. То есть знания о бэкдоре уже не под контролем NSA, и leak может выйти в любой момент. То есть количество людей, которые могут поднять скандал, возможно даже выше, чем на практике в опенсоурсе.
Я сдаюсь, посмотри хотя бы советские фильмы про разведчиков. Они, конечно, большей частью сказка, но тем ни менее являются отражением деятельности спецслужб.
З.Ы. Ну и скромненький вопрос, ты "форму" когда-либо подписывал? А читал, что подписывал?
Здравствуйте, Vzhyk, Вы писали:
V>Но, я писал немного о другом, о том, что никто им не может помешать предложить конторе самой сделать бэкдур в проприетарном софте для них.
Не может. Но это менее надежный в долгосрочной перспективе способ, т.к. если список такого софта или хоть какая-то его часть будет озвучен очередным снуоденом (что собственно нынешний сноуден и сделал), то подобные бэкдоры буду моментально закрыты либо поставщики софта просто растеряют своих клиентов.
V>Остался только один нюанс. В опенсурсном есть шанс, что кто-то когда-то засунет нос и поднимет скандал,
Если бы "сунуть нос" было так просто... В truecrypt, например, уже с начала года суют нос на предмет бэкдоров, причем не парни с обочины, а профессионалы и на коммерческой основе. А проделано только пол работы (http://istruecryptauditedyet.com/) и самая тяжелая часть еще впереди
V>а вот для проприетарного и такого шанса нет.
Ну почему же. В бинарщину точно также можно сунуть нос, только потратить на это придется примерно в 3-4 раза больше времени, чем при работе с исходниками (это мой личный и давний опыт, допускаю, что он не репрезентативен, пусть меня поправят, если так).
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Ну почему же. В бинарщину точно также можно сунуть нос, только потратить на это придется примерно в 3-4 раза больше времени, чем при работе с исходниками.
Видишь какой серьезный аргумент в пользу опенсурс. А найденые дырки в опенсурсе засвечиваются с меньшими затратами, чем в проприетарном и, если они кого-то волнуют, закрываются.
Посему открытый софт с точки зрения безопасности использовать лучше и дешевле.
И с truecrypt ты хороший пример привел. А вот как получил ты код для исследования чего-то проприетарного. А сейчас поисследуют и если найдут дырки, то закроют их. Правда вариант с "Большим Братом" все одно остается — могут не все найденные дырки закрыть, но там подписки о неразглашении и турма в США или в РФ бежать. И нет гарантии, что следующего "Сноудена" РФ прикроет. С этим товарищем у меня вообще ощущение, что он уже давно российским разведчиком был и когда запахло раскрытием его вывезли, попутно подложив большую свинью американцам.
Здравствуйте, a_g_99, Вы писали:
V>>Если вспомнить, какие люди работают в подобных структурах, то наоборот становится удивительным, что они нашли и эксплуатировали эту дырку в опенсурсе. Более логичное и естественное их поведение пригласить директора конторы некоего проприетарного софта к себе в контору (или самим в гости зайти) и попросить сделать для них бэкдуру в их софте.
__>Вы штаты с белорусь перепутали.
Шо за децкий сад? Следите за новостями, в последнее время всплыло куча инфы о бекдорах. Начиная с RSA Security.
В т.ч. с немыслимыми тоталитарными вывертами вроде gag orders. Т.е. заставляют вствлять бекдоры и при этом
заставляют молчать об этом требовании под страхом тюрьмы.
Откуда же его [независимый суд] взять, если в нем такие же как мы? (c) VladD2
Здравствуйте, мыщъх, Вы писали:
М>вам рекомендуют пользоваться версиями первой (в крайнем случае второй) свежести. но как ими пользоваться, если на старом дистре для этого нужно обновлять 100500 библиотек и не факт, что ранее установленные пакеты не отвалятся и ничего не поломается?
А не надо юзать "стабильные дистры", у которых в основной репе говно мамонта. Я про дебиан и центос, если что. С любителями этих двух кусков говна лично я даже спорить уже не хочу.
D>А не надо юзать "стабильные дистры", у которых в основной репе говно мамонта. Я про дебиан и центос, если что. С любителями этих двух кусков говна лично я даже спорить уже не хочу.
Занятный факт: "говно мамонта" (С) Debian на openssl 0.9.8 ветке не пострадало. И CentOS вплоть до самого-самого нового (6.5) тоже не страдал. ибо был на 1.0.0.
Здравствуйте, SkyDance, Вы писали:
D>>А не надо юзать "стабильные дистры", у которых в основной репе говно мамонта. Я про дебиан и центос, если что. С любителями этих двух кусков говна лично я даже спорить уже не хочу.
SD>Занятный факт: "говно мамонта" (С) Debian на openssl 0.9.8 ветке не пострадало. И CentOS вплоть до самого-самого нового (6.5) тоже не страдал. ибо был на 1.0.0.
That was random. А вот проблема с установкой софта посвежее — системная и потому вечная.
Здравствуйте, kleng, Вы писали:
V>>Видишь какой серьезный аргумент в пользу опенсурс. K>На самом деле, это аргумент против опенсорс.
Как это? Т.е. возможность найти или устранить уязвимость всем, это не аргумент уже?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
V>Как это? Т.е. возможность найти или устранить уязвимость всем, это не аргумент уже?
Всем? А вот скажи, к примеру, а какое количество уязвимостей нашел (ограничиваться опенсорсом и углубляться на тему "устранил" пока даже не будем) конкретно ты? А в скольких проектах ты их вообще пробовал искать? Вопрос риторический, конечно же. Забавно тут то, что у 99.9% стороннников опенсорса порядок этого числа точно такой же. Но при этом каждый считает, что конечно не он, но уж точно кто-нибудь другой — обязательно воспользуется этой возможностью.
Да вот только, с чего бы? Анализ защищенности того же truecrypt'а — задача: а) не для разработчика (немного не та предметная область), б) на десятки человеко-часов _минимум_, чтобы от нее был хоть какой-то толк. Ну и какое количество глаз из всех этих миллионов пар, обладает достаточной квалификацией в нужной предметной области и готово положить десятки часов своего времени на то, чтобы бесплатно выполнить свою весьма высокооплачиваемую работу? Ответ будет исчисляться несколькими десятками человек, работающих в корпорациях, в проектах которых используется какой-либо сторонний opensource-код, в защищенности которого корпорации, разумеется, заинтересованы. Это при условии, что компания поделится патчами с сообществом (что вообще-то редкость). А теперь раздели получившееся число на количество хотя бы только популярных opensource-проектов. А как быть проектам, код которых не используется корпорациями? Ждать по 10 лет фанатика, который перелопатит им весь код ради самопиара на очередной конференции? А ничего, что обеспечение защищенности кода вообще-то должно являться частью жизненного цикла разработки ПО, а не разовым проектом на волне энтузиазма?
И аргументом здесь как раз и является то, что при наличии у любого члена сообщества отнюдь не безызвестного проекта возможности найти или устранить уязвимость, ему (вместе с авторами проекта) — приходится собирать деньги на то, чтобы оплатить поиск уязвимостей в нем, причем даже не сообществом, а компанией-вендором услуг анализа защищенности, согласишейся помочь проекту за символическую для такого объема работ плату в несколько тысяч долларов. Так в каком месте тут проявилась возможность "найти или устранить уязвимость всем"?
Здравствуйте, Algebroid, Вы писали:
A>АНБ само заинтересовано в секьюрной ОС для своих компьютеров. Или у них только коммерческий Юникс?
Насколько я помню, в качестве рабочих мест там используется винда, вообще-то Но даже, если АНБ будет принимать участие в повышении защищенности какой-либо открытой системы, ничто не мешает ей: а) вообще не делиться патчами, б) делиться ими лишь частично, в) делиться модифицированными патчами с лазейками для себя хороших
Здравствуйте, Vain, Вы писали:
V>>>Видишь какой серьезный аргумент в пользу опенсурс. K>>На самом деле, это аргумент против опенсорс. V>Как это? Т.е. возможность найти или устранить уязвимость всем, это не аргумент уже?
Это разве не работает в обе стороны: возможность найти и эксплуатировать уязвимость тоже легче в эти самые разы?
Здравствуйте, Yoriсk, Вы писали:
Y>Это разве не работает в обе стороны: возможность найти и эксплуатировать уязвимость тоже легче в эти самые разы?
Код конечен. И теоретически количество уязвимостей будет уменьшаться и станет нулевым через некоторое время.
Здравствуйте, Vzhyk, Вы писали:
V>Код конечен. И теоретически количество уязвимостей будет уменьшаться и станет нулевым через некоторое время.
Это теоретизация в том же направлении, что и "память компьютера конечна, поэтому любая программа может быть описана конечным автоматом" Код не статичем (если мы не об уже мертвом проекте, конечно), он меняется с каждым коммитом. С каждым коммитом количество уязвимостей в нем может как увеличиваться, так и уменьшаться. Именно поэтому модель обеспечения защищенноти "кто-нибудь, когда-нибудь, один раз посмотрит и может быть найдет уявзимость" — попросту не работает. Также, как и если после проведения аудита, авторами truecrypt не будет налажен SDLC, то собранные сообществом деньги окажется выброшенными на ветер, в общем-то.
Здравствуйте, kochetkov.vladimir, Вы писали:
V>>Как это? Т.е. возможность найти или устранить уязвимость всем, это не аргумент уже? KV>Всем? А вот скажи, к примеру, а какое количество уязвимостей нашел (ограничиваться опенсорсом и углубляться на тему "устранил" пока даже не будем) конкретно ты? А в скольких проектах ты их вообще пробовал искать?
А это имеет значение? Тут важна сама возможность это сделать. Тот кто пользует код из опенсорса тот и отсылает патчи/фиксы.
Но если брать конкретно меня, то как минимум расширял boost.preprocessor. Пойдёт?
KV>Вопрос риторический, конечно же.
Это вопрос вообще мимо кассы. Каждый сам волен решать. А вот когда возможности нет, то и если захочешь — не пофиксишь. Потому-что это будет зависить от левой ноги правообладателя приватными софтом.
KV>Забавно тут то, что у 99.9% стороннников опенсорса порядок этого числа точно такой же. Но при этом каждый считает, что конечно не он, но уж точно кто-нибудь другой — обязательно воспользуется этой возможностью.
Это неверное толкование опен сорса. Верное — сама доступность исходников и возможность исправить там что-то делает опен сорс опен сорсом. Это его определение. Ты щас взялся его каверкать на свой лад.
KV>Да вот только, с чего бы? Анализ защищенности того же truecrypt'а — задача: а) не для разработчика (немного не та предметная область),
А ты не думал что те кто его используют могут разбираться в деталях шифрования?
KV>б) на десятки человеко-часов _минимум_, чтобы от нее был хоть какой-то толк. Ну и какое количество глаз из всех этих миллионов пар, обладает достаточной квалификацией в нужной предметной области и готово положить десятки часов своего времени на то, чтобы бесплатно выполнить свою весьма высокооплачиваемую работу?
Они могут выполнить эту работу для себя, получить прибыль, а потом открыть исходники. В чём проблема?
KV>Ответ будет исчисляться несколькими десятками человек, работающих в корпорациях, в проектах которых используется какой-либо сторонний opensource-код, в защищенности которого корпорации, разумеется, заинтересованы. Это при условии, что компания поделится патчами с сообществом (что вообще-то редкость).
Редкость да происходит.
KV>И аргументом здесь как раз и является то, что при наличии у любого члена сообщества отнюдь не безызвестного проекта возможности найти или устранить уязвимость, ему (вместе с авторами проекта) — приходится собирать деньги на то, чтобы оплатить поиск уязвимостей в нем, причем даже не сообществом, а компанией-вендором услуг анализа защищенности, согласишейся помочь проекту за символическую для такого объема работ плату в несколько тысяч долларов. Так в каком месте тут проявилась возможность "найти или устранить уязвимость всем"?
То что кто-то не хочет делать что-то, из этого не следует что все остальные не будут.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Yoriсk, Вы писали:
V>>>>Видишь какой серьезный аргумент в пользу опенсурс. K>>>На самом деле, это аргумент против опенсорс. V>>Как это? Т.е. возможность найти или устранить уязвимость всем, это не аргумент уже? Y>Это разве не работает в обе стороны: возможность найти и эксплуатировать уязвимость тоже легче в эти самые разы?
И? А закладки в приватном софте ещё более легче и вообще никто не узнает. Самой возможности узнать и проверить не будет.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
V>И? А закладки в приватном софте ещё более легче и вообще никто не узнает. Самой возможности узнать и проверить не будет.
Кстати, у разработчиков действительно есть такое мнение, сложившееся в результате того, что большую часть своего времени они работают с исходным кодом. Анализ бинарников сложнее, но в общем случае, это лишь несколько увеличивает время анализа, но не делает его невозможным или неосуществимым за разумное время.
Здравствуйте, Vain, Вы писали:
V>А это имеет значение? Тут важна сама возможность это сделать.
Наличие одной только возможности это сделать — ничего не значит без наличия желания и умения это делать
V>Тот кто пользует код из опенсорса тот и отсылает патчи/фиксы.
Во-первых, заметь это уже не "все", а только те, кто используют Во-вторых, почему при таком количестве использующих код X11, одномоментно в нем обнаружилось свыше 120 багов, самому старшему из которых было около 23 лет. Только, пожалуйста, не надо "но ведь обнаружилось же". При 0-day возрастом 23 года говорить о "преимуществах" защищенности опернсорса уже просто смешно Почему heartbleed просуществовал в openssl около 2 лет, если его код использовался в подавляющем большинстве аппаратных файрволов и роутеров?
V>Но если брать конкретно меня, то как минимум расширял boost.preprocessor. Пойдёт?
Нет (хотя, сам факт посильного участия в открытых проектах — всегда заслуживает уважения ), я имею ввиду именно участие по поиску и устранению уязвимостей.
KV>>Вопрос риторический, конечно же. V>Это вопрос вообще мимо кассы. Каждый сам волен решать. А вот когда возможности нет, то и если захочешь — не пофиксишь. Потому-что это будет зависить от левой ноги правообладателя приватными софтом.
А я и не утверждаю, что проприетарная модель разработки имеет преимущества перед открытой. Я утверждаю, что те преимущества, которые дает открытая модель, по факту не могут влиять положительным образом на защищенность разрабатываемого продукта.
KV>>Забавно тут то, что у 99.9% стороннников опенсорса порядок этого числа точно такой же. Но при этом каждый считает, что конечно не он, но уж точно кто-нибудь другой — обязательно воспользуется этой возможностью. V>Это неверное толкование опен сорса. Верное — сама доступность исходников и возможность исправить там что-то делает опен сорс опен сорсом. Это его определение. Ты щас взялся его каверкать на свой лад.
Так это не мое толкование, а тех, чью точку зрения я здесь и оспариваю
KV>>Да вот только, с чего бы? Анализ защищенности того же truecrypt'а — задача: а) не для разработчика (немного не та предметная область), V>А ты не думал что те кто его используют могут разбираться в деталях шифрования?
Почему только шифрования? Анализ защищенности кода не сводится к криптоанализу используемых в нем алгоритмов и доказательства корректности их реализации. Это совсем малая часть от всего множества задач анализа. Тем не менее, отвечая на твой вопрос: да, разумеется могут, но их количество исчезающе мало((. А в том, что касается разработчиков, конкретно я — каждый день об этом думаю Видишь ли, я и мои коллеги сейчас ищем разработчика ко мне в группу для работы на ядром анализа C#-кода в этом
продукте. Вакансия есть в "предложениях от работодателей" здесь, на RSDN. От разработчика требуется ровно две вещи: хорошо владеть C# (никакх WPF, WCF, MVC и т.п. — чистый CUI) и иметь представление об уязвимостях в веб-приложениях, какие недостатки их обуславливают и какие атаки возможны на эти уязвимости. Всему остальному — научим. Да и второму пункту тоже готовы обучить (в разумных пределах, разумеется). Вакансия в Питере, з/п — от 80 т.р. (днище для студентов без опыта) и выше, причем в действительно широких пределах (хоть в два раза, лишь бы человек был хороший, полезный проекту и которого не надо будет обучать матчасти). Насколько я знаю, для Питера это очень неплохое предложение для несеньерской позиции, разве нет? Так вот, при достаточном количестве претендентов, до собеседования за пару месяцев добрались единицы, а собеседование пока еще не прошел никто, причем именно из-за второго пункта требований и желания разобраться в этой предметной области =/ Думали, может такой народ есть, просто сильно держится за свои текущие места... так вроде нет, насколько удалось поузнавать
Поэтому, если у тебя есть разработчики, способные к поиску и устранению уязвимостей (или хотя бы желающие в этом разобраться) — просто направь их ко мне, плс. Но пока что, опыт последних двух месяцев говорит мне, что таких разработчиков не слишком много, мягко говоря. По крайней мере, в Питере))
KV>>б) на десятки человеко-часов _минимум_, чтобы от нее был хоть какой-то толк. Ну и какое количество глаз из всех этих миллионов пар, обладает достаточной квалификацией в нужной предметной области и готово положить десятки часов своего времени на то, чтобы бесплатно выполнить свою весьма высокооплачиваемую работу? V>Они могут выполнить эту работу для себя, получить прибыль, а потом открыть исходники. В чём проблема?
Под работой, я имел ввиду проведение анализа защищенности открытого кода. Какие исходники они должны открыть и какую прибыль в этом случае они получат?
V>То что кто-то не хочет делать что-то, из этого не следует что все остальные не будут.
Как и из того, что все могут делать что-то, еще не следует, что хоть кто-то будет
Здравствуйте, kochetkov.vladimir, Вы писали:
V>>И? А закладки в приватном софте ещё более легче и вообще никто не узнает. Самой возможности узнать и проверить не будет. KV>Кстати, у разработчиков действительно есть такое мнение, сложившееся в результате того, что большую часть своего времени они работают с исходным кодом. Анализ бинарников сложнее, но в общем случае, это лишь несколько увеличивает время анализа, но не делает его невозможным или неосуществимым за разумное время.
Ты смеёшься чтоли? Кто ж бинари будет анализировать? И потом, как ты выкатишь это? В исходники можно хотя бы носом ткнуть.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, kochetkov.vladimir, Вы писали:
V>>А это имеет значение? Тут важна сама возможность это сделать. KV>Наличие одной только возможности это сделать — ничего не значит без наличия желания и умения это делать
А без её наличия желание и умение тебе уже не помогут.
V>>Тот кто пользует код из опенсорса тот и отсылает патчи/фиксы. KV>Во-первых, заметь это уже не "все", а только те, кто используют Во-вторых, почему при таком количестве использующих код X11, одномоментно в нем обнаружилось свыше 120 багов, самому старшему из которых было около 23 лет.
Видимо тесты решили написать?
KV>Только, пожалуйста, не надо "но ведь обнаружилось же". При 0-day возрастом 23 года говорить о "преимуществах" защищенности опернсорса уже просто смешно
А что, в приватном софте не бывает таких багов? И при чём здесь опен сорс?
V>>Но если брать конкретно меня, то как минимум расширял boost.preprocessor. Пойдёт? KV>Нет (хотя, сам факт посильного участия в открытых проектах — всегда заслуживает уважения ), я имею ввиду именно участие по поиску и устранению уязвимостей.
Поиск и устранение уязвимостей в существующем софте задача сложнее, чем написание этого самого софта. Так что не удивительно что есть баги которые никто пока не нашёл.
KV>А я и не утверждаю, что проприетарная модель разработки имеет преимущества перед открытой. Я утверждаю, что те преимущества, которые дает открытая модель, по факту не могут влиять положительным образом на защищенность разрабатываемого продукта.
Откуда ты знаешь что не могут? На основе чего вывод?
KV>>>Да вот только, с чего бы? Анализ защищенности того же truecrypt'а — задача: а) не для разработчика (немного не та предметная область), V>>А ты не думал что те кто его используют могут разбираться в деталях шифрования?
KV>Почему только шифрования? Анализ защищенности кода не сводится к криптоанализу используемых в нем алгоритмов и доказательства корректности их реализации. Это совсем малая часть от всего множества задач анализа. Тем не менее, отвечая на твой вопрос: да, разумеется могут, но их количество исчезающе мало((. А в том, что касается разработчиков, конкретно я — каждый день об этом думаю Видишь ли, я и мои коллеги сейчас ищем разработчика ко мне в группу для работы на ядром анализа C#-кода в этом
продукте. Вакансия есть в "предложениях от работодателей" здесь, на RSDN. От разработчика требуется ровно две вещи: хорошо владеть C# (никакх WPF, WCF, MVC и т.п. — чистый CUI) и иметь представление об уязвимостях в веб-приложениях, какие недостатки их обуславливают и какие атаки возможны на эти уязвимости. Всему остальному — научим. Да и второму пункту тоже готовы обучить (в разумных пределах, разумеется). Вакансия в Питере, з/п — от 80 т.р. (днище для студентов без опыта) и выше, причем в действительно широких пределах (хоть в два раза, лишь бы человек был хороший, полезный проекту и которого не надо будет обучать матчасти). Насколько я знаю, для Питера это очень неплохое предложение для несеньерской позиции, разве нет? Так вот, при достаточном количестве претендентов, до собеседования за пару месяцев добрались единицы, а собеседование пока еще не прошел никто, причем именно из-за второго пункта требований и желания разобраться в этой предметной области =/ Думали, может такой народ есть, просто сильно держится за свои текущие места... так вроде нет, насколько удалось поузнавать
Так ниша то оччень узкая. Ктож готов тратить своё время на изучение такого, что потом, после смены работы, оно вдруг не нужно окажется? Вы врятли такого найдёте. Обычно такие "выращиваются" за счёт фирмы.
KV>Поэтому, если у тебя есть разработчики, способные к поиску и устранению уязвимостей (или хотя бы желающие в этом разобраться) — просто направь их ко мне, плс. Но пока что, опыт последних двух месяцев говорит мне, что таких разработчиков не слишком много, мягко говоря. По крайней мере, в Питере))
Не, таких знакомых у меня наверно не найдётся.
KV>>>б) на десятки человеко-часов _минимум_, чтобы от нее был хоть какой-то толк. Ну и какое количество глаз из всех этих миллионов пар, обладает достаточной квалификацией в нужной предметной области и готово положить десятки часов своего времени на то, чтобы бесплатно выполнить свою весьма высокооплачиваемую работу? V>>Они могут выполнить эту работу для себя, получить прибыль, а потом открыть исходники. В чём проблема? KV>Под работой, я имел ввиду проведение анализа защищенности открытого кода. Какие исходники они должны открыть и какую прибыль в этом случае они получат?
Обычно дыры исправляют после того как кто-то их обнаружил и обнаружил, возможно, случайно. Специально их искать — задача по сложности сопоставимая с самим написанием софта, который тестируется, а чаще — ещё сложнее. Да и влияет ли присутствие ненайденных дыр на прибыль некой компании? Думаю что нет. Компании выгоднее продвигать продукт, а не искать дыры в безопасности. А дыры пусть ищут те, кто специально специализируются на этом.
V>>То что кто-то не хочет делать что-то, из этого не следует что все остальные не будут. KV>Как и из того, что все могут делать что-то, еще не следует, что хоть кто-то будет
Ты не знаешь этого. К тому же есть положительные примеры когда дыры в опенсорсе находили сторонние разработчики.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
V>>>Как это? Т.е. возможность найти или устранить уязвимость всем, это не аргумент уже? Y>>Это разве не работает в обе стороны: возможность найти и эксплуатировать уязвимость тоже легче в эти самые разы? V>И? А закладки в приватном софте ещё более легче и вообще никто не узнает. Самой возможности узнать и проверить не будет.
По такой логике в закрытом софте об уязвимостях вообще никто узнает, самой возможности узнать и эксплуатировать не будет.
Здравствуйте, Yoriсk, Вы писали:
V>>>>Как это? Т.е. возможность найти или устранить уязвимость всем, это не аргумент уже? Y>>>Это разве не работает в обе стороны: возможность найти и эксплуатировать уязвимость тоже легче в эти самые разы? V>>И? А закладки в приватном софте ещё более легче и вообще никто не узнает. Самой возможности узнать и проверить не будет. Y>По такой логике в закрытом софте об уязвимостях вообще никто узнает, самой возможности узнать и эксплуатировать не будет.
У АНБ то?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
V>>>И? А закладки в приватном софте ещё более легче и вообще никто не узнает. Самой возможности узнать и проверить не будет. Y>>По такой логике в закрытом софте об уязвимостях вообще никто узнает, самой возможности узнать и эксплуатировать не будет. V>У АНБ то?
Здравствуйте, Yoriсk, Вы писали:
V>>>>И? А закладки в приватном софте ещё более легче и вообще никто не узнает. Самой возможности узнать и проверить не будет. Y>>>По такой логике в закрытом софте об уязвимостях вообще никто узнает, самой возможности узнать и эксплуатировать не будет. V>>У АНБ то? Y>У ZOG.
Ты зря дурака включил
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
V>Ты смеёшься чтоли? Кто ж бинари будет анализировать? И потом, как ты выкатишь это? В исходники можно хотя бы носом ткнуть.
Это что, стёб такой?
Откуда же его [независимый суд] взять, если в нем такие же как мы? (c) VladD2
Здравствуйте, ins-omnia, Вы писали:
V>>Ты смеёшься чтоли? Кто ж бинари будет анализировать? И потом, как ты выкатишь это? В исходники можно хотя бы носом ткнуть. IO>Это что, стёб такой?
Нет. Ты действительно считаешь что без исходников и дебаг инфы можно баг в исходниках найти?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
V>>>Ты смеёшься чтоли? Кто ж бинари будет анализировать? И потом, как ты выкатишь это? В исходники можно хотя бы носом ткнуть. IO>>Это что, стёб такой? V>Нет. Ты действительно считаешь что без исходников и дебаг инфы можно баг в исходниках найти?
Не понял что значит "баг в исходниках". Баг конечно же в бинарниках. Найти такие баги безусловно можно.
Собственно баги в бинарном проприетарном софте находят постоянно. Это рутина вообще-то.
Откуда же его [независимый суд] взять, если в нем такие же как мы? (c) VladD2
Здравствуйте, ins-omnia, Вы писали:
V>>>>Ты смеёшься чтоли? Кто ж бинари будет анализировать? И потом, как ты выкатишь это? В исходники можно хотя бы носом ткнуть. IO>>>Это что, стёб такой? V>>Нет. Ты действительно считаешь что без исходников и дебаг инфы можно баг в исходниках найти? IO>Не понял что значит "баг в исходниках". Баг конечно же в бинарниках. Найти такие баги безусловно можно. IO>Собственно баги в бинарном проприетарном софте находят постоянно. Это рутина вообще-то.
А толку то от того что ты найдёшь? Как ты его пофиксишь то?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
IO>>Собственно баги в бинарном проприетарном софте находят постоянно. Это рутина вообще-то. V>А толку то от того что ты найдёшь? Как ты его пофиксишь то?
Баги в чужом проприетарном софте ищут не для того чтобы их фиксить, а для того чтобы
— их эксплуатировать
— не эксплуатировать, но использовать эту находку для самопиара, поиска работы и т.п.
Откуда же его [независимый суд] взять, если в нем такие же как мы? (c) VladD2
Здравствуйте, ins-omnia, Вы писали:
IO>>>Собственно баги в бинарном проприетарном софте находят постоянно. Это рутина вообще-то. V>>А толку то от того что ты найдёшь? Как ты его пофиксишь то? IO>Баги в чужом проприетарном софте ищут не для того чтобы их фиксить, а для того чтобы IO>- их эксплуатировать IO>- не эксплуатировать, но использовать эту находку для самопиара, поиска работы и т.п.
Причём здесь опенсорс тогда?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
IO>>Баги в чужом проприетарном софте ищут не для того чтобы их фиксить V>Причём здесь опенсорс тогда?
Контекст ветки: V>И? А закладки в приватном софте ещё более легче и вообще никто не узнает. Самой возможности узнать и проверить не будет KV>Анализ бинарников сложнее, но в общем случае, это лишь несколько увеличивает время анализа, но не делает его невозможным или неосуществимым за разумное время.
(выделение моё)
Откуда же его [независимый суд] взять, если в нем такие же как мы? (c) VladD2
Здравствуйте, ins-omnia, Вы писали:
IO>>>Баги в чужом проприетарном софте ищут не для того чтобы их фиксить V>>Причём здесь опенсорс тогда? IO>Контекст ветки: V>>И? А закладки в приватном софте ещё более легче и вообще никто не узнает. Самой возможности узнать и проверить не будет KV>>Анализ бинарников сложнее, но в общем случае, это лишь несколько увеличивает время анализа, но не делает его невозможным или неосуществимым за разумное время. IO>(выделение моё) IO>
Обсуждение началось вот отсюда: http://rsdn.ru/forum/flame.comp/5559919.1
Тема ветки про опенсорс в сравнении с приватным. Так вот опенсорс правится легко, приватный — нет. Почему — я уже сказал. Причём здесь бинари и как их анализ поможет исправить баги — непонятно.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
IO>>Собственно баги в бинарном проприетарном софте находят постоянно. Это рутина вообще-то. V>А толку то от того что ты найдёшь? Как ты его пофиксишь то?
Пишешь вендору, он фиксит. Или не пишешь и тихоноко эксплуатируешь уязвимость.
Как в опенсорс примерно.
Здравствуйте, Yoriсk, Вы писали:
IO>>>Собственно баги в бинарном проприетарном софте находят постоянно. Это рутина вообще-то. V>>А толку то от того что ты найдёшь? Как ты его пофиксишь то? Y>Пишешь вендору, он фиксит.
Пишешь вендору — он не фиксит. Далнейшие действия?
Y>Или не пишешь и тихоноко эксплуатируешь уязвимость. Y>Как в опенсорс примерно.
Мимо. Как и ВЕЗДЕ.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Evgeniy Skvortsov, Вы писали:
V>>Ты зря дурака включил ES>имхо, дурака включил как раз ты, причем намного раньше по ветке.
Конретно ответ был про опенсорс в сравнении с приватным. Поиск уязвимостей никак не связан с открытостью исходников. Но с открытыми исходниками у тебя имеется прямая возможность исправить багу/дыру. Сколько мне раз это надо повторить?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
IO>>>>Собственно баги в бинарном проприетарном софте находят постоянно. Это рутина вообще-то. V>>>А толку то от того что ты найдёшь? Как ты его пофиксишь то? Y>>Пишешь вендору, он фиксит. V>Пишешь вендору — он не фиксит. Далнейшие действия?
Да то же самое что и в опенсурсе — грустить.
Баг найти это одно, правильно починить ничего не сломав — сильно другое.
Особенно в security critical code, особенно в такой помойке как сурсы OpenSSL.
Здравствуйте, Vain, Вы писали:
... V>Конретно ответ был про опенсорс в сравнении с приватным. Поиск уязвимостей никак не связан с открытостью исходников. Но с открытыми исходниками у тебя имеется прямая возможность исправить багу/дыру. Сколько мне раз это надо повторить?
повторять не надо — достаточно хранить историю успешно исправленных в опенсорсе дыр и при случае ею хвастаться. а до тех пор это все потенциальные возможности исправить, до которых дела никому нет.
Здравствуйте, CreatorCray, Вы писали:
V>>Пишешь вендору — он не фиксит. Далнейшие действия? CC>Да то же самое что и в опенсурсе — грустить.
А вот и не то же. В опесорсе ты пишешь патч (благо для дыр в безопасности они обычно маленькие),
компилируешь пакет для своего дистрибутива и забывыешь о проблеме. Или скорее всего это делает мантейнер
пакета для твоего дистрибутива.
А в проприетарщине ты не грустишь, а идешь на ч0рный рынок продавать зеродей.
Откуда же его [независимый суд] взять, если в нем такие же как мы? (c) VladD2
Здравствуйте, CreatorCray, Вы писали:
CC>Да то же самое что и в опенсурсе — грустить.
У вас в опенсорсе зудит что вы его так не любите? Это не тоже самое, потому-что не эквивалентно.
CC>Баг найти это одно, правильно починить ничего не сломав — сильно другое. CC>Особенно в security critical code, особенно в такой помойке как сурсы OpenSSL.
Это не объясняет того, что этого нельзя сделать.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, SleepyDrago, Вы писали:
SD>... V>>Конретно ответ был про опенсорс в сравнении с приватным. Поиск уязвимостей никак не связан с открытостью исходников. Но с открытыми исходниками у тебя имеется прямая возможность исправить багу/дыру. Сколько мне раз это надо повторить? SD>повторять не надо — достаточно хранить историю успешно исправленных в опенсорсе дыр и при случае ею хвастаться. а до тех пор это все потенциальные возможности исправить, до которых дела никому нет.
Не надо за всех говорить. Я лично находил и исправлял в SISL'е баги. Софт был куплен, но и открыт под GPL.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, ins-omnia, Вы писали:
IO>А вот и не то же. В опесорсе ты пишешь патч (благо для дыр в безопасности они обычно маленькие), IO>компилируешь пакет для своего дистрибутива и забывыешь о проблеме.
Или получаешь проблему ещё больше, потому как не учёл какой либо аспект.
Здравствуйте, Vain, Вы писали:
CC>>Да то же самое что и в опенсурсе — грустить. V>У вас в опенсорсе зудит что вы его так не любите?
Я видел много опенсорса и в среднем качество кода там меня сильно огорчает.
Очень мало проектов в которых наведена дисциплина и код пишут и комментируют согласно единому и вменяемому стандарту.
CC>>Баг найти это одно, правильно починить ничего не сломав — сильно другое. CC>>Особенно в security critical code, особенно в такой помойке как сурсы OpenSSL. V>Это не объясняет того, что этого нельзя сделать.
Сделать то можно, вопрос в требуемых усилиях.
Здравствуйте, CreatorCray, Вы писали:
CC>>>Да то же самое что и в опенсурсе — грустить. V>>У вас в опенсорсе зудит что вы его так не любите? CC>Я видел много опенсорса и в среднем качество кода там меня сильно огорчает.
Это не потому то ли что ты его можешь видеть за бесплатно?
CC>Очень мало проектов в которых наведена дисциплина и код пишут и комментируют согласно единому и вменяемому стандарту.
Это что за стандарт такой — вменяемый?
CC>>>Баг найти это одно, правильно починить ничего не сломав — сильно другое. CC>>>Особенно в security critical code, особенно в такой помойке как сурсы OpenSSL. V>>Это не объясняет того, что этого нельзя сделать. CC>Сделать то можно, вопрос в требуемых усилиях.
Тому кому надо, прилагает ровно столько же усилий, сколько прилагает и к приватному софту.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
V>Это не потому то ли что ты его можешь видеть за бесплатно?
Нет.
CC>>Очень мало проектов в которых наведена дисциплина и код пишут и комментируют согласно единому и вменяемому стандарту. V>Это что за стандарт такой — вменяемый?
Это который логичен и обоснован.
Здравствуйте, CreatorCray, Вы писали:
V>>Это не потому то ли что ты его можешь видеть за бесплатно? CC>Нет.
Отрицаешь очевидное?
CC>>>Очень мало проектов в которых наведена дисциплина и код пишут и комментируют согласно единому и вменяемому стандарту. V>>Это что за стандарт такой — вменяемый? CC>Это который логичен и обоснован.
Какой из 100500 логичных и обоснованных?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, CreatorCray, Вы писали:
IO>>А вот и не то же. В опесорсе ты пишешь патч (благо для дыр в безопасности они обычно маленькие), IO>>компилируешь пакет для своего дистрибутива и забывыешь о проблеме. CC>Или получаешь проблему ещё больше, потому как не учёл какой либо аспект.
В сравнении с проприетарным это проблема вообще никакая, это аспект потом правиться также.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
V>Ты смеёшься чтоли? Кто ж бинари будет анализировать?
Тот, кто имеет навыки реверсинга и анализа защищенности бинарников (тысячи их, просто это не ваши, а наши коллеги)). Так же, как и анализом исходников занимался бы тот, кто имеет навыки анализа защищенности исходников (а не их разработки, опять-таки, что часто упускают из вида сторонники опенсорса).
V>И потом, как ты выкатишь это? В исходники можно хотя бы носом ткнуть.
В бинарники тоже. Собственно, есть универсальный способ ткнуть носом безотносительно того, бинарь это или исходник — показать рабочий эксплоит. Что касается возможности патчить, то во-первых, это не делает опенсорс защищеннее закрытого кода по умолчанию (напомню, что мы об этом, вообще-то), во-вторых, почти всегда можно найти обходное решение, которое позволит устранить обнаруженную уязвимость, не влезая в уязвимый код, а в-третьих, подготовить правильно работающий патч, не вносящий новые уязвимости и ничего не ломающий — не так просто, как может показаться. Я убедился в этом на собственном опыте, например, когда пытался самостоятельно пропатчить http://mailman.nginx.org/pipermail/nginx-announce/2012/000086.html и отбраковал 5 вариантов исправления, потому что они позволяли обойти ограничения уже другими способами, либо на другой платформе. В итоге, обошелся воркарраундом, а патч подготовили те, кто знал этот код "чуть" лучше меня — его авторы.
Здравствуйте, Vain, Вы писали:
V>Ты смеёшься чтоли? Кто ж бинари будет анализировать?
Это тебе мыщчъх расскажет как их анализировать. Были бы правильные тулы и желание.
V> И потом, как ты выкатишь это?
Ну я пару раз выкатывал патчи в виде "offset: bytes заменить на bytes" к чужим бинарям.
V> В исходники можно хотя бы носом ткнуть.
А толку. Порой там такие исходники что в бинаре куда чётче проблему видно чем в том макроспагетти что в сурсах наиндусили.
Здравствуйте, Vain, Вы писали:
V>А без её наличия желание и умение тебе уже не помогут.
Возможность найти уязвимость существует всегда. В отличии от желания и умения.
V>Видимо тесты решили написать?
Нет, код впервые за время существования проекта посмотрел тот, кто умел искать уязвимости. После его репорта авторы решили просканировать код каким-то бесплатным анализатором и в пачке обнаруженных еще и им недостатков, как раз и всплыла уязвимость, которой было 23 года.
V>А что, в приватном софте не бывает таких багов?
Мы сейчас не про приватный софт.
V>И при чём здесь опен сорс?
Не причем. Его защищенность ни чем не лучше защищенности закрытого кода, я только об этом тут и говорю
V>Поиск и устранение уязвимостей в существующем софте задача сложнее, чем написание этого самого софта. Так что не удивительно что есть баги которые никто пока не нашёл.
Учитывая, что поиск уязвимостей решается исключительно аналитически (т.к. это алгоритмически неразрешимая задача), то да, сложнее. Вот только это справедливо для любого кода и не зависит от того, открыт он или нет.
KV>>А я и не утверждаю, что проприетарная модель разработки имеет преимущества перед открытой. Я утверждаю, что те преимущества, которые дает открытая модель, по факту не могут влиять положительным образом на защищенность разрабатываемого продукта. V>Откуда ты знаешь что не могут? На основе чего вывод?
Я только и делаю в этой теме, что привожу аргументы в пользу этого довода
V>есть положительные примеры когда дыры в опенсорсе находили сторонние разработчики.
а есть отрицательные, причем прямо в этой и соседней темах Подобное обычно и называют "палка о двух концах", если что.
Здравствуйте, kochetkov.vladimir, Вы писали:
V>>Ты смеёшься чтоли? Кто ж бинари будет анализировать? KV>Тот, кто имеет навыки реверсинга и анализа защищенности бинарников (тысячи их, просто это не ваши, а наши коллеги)). Так же, как и анализом исходников занимался бы тот, кто имеет навыки анализа защищенности исходников (а не их разработки, опять-таки, что часто упускают из вида сторонники опенсорса).
V>Тот кто пользует код из опенсорса тот и отсылает патчи/фиксы.
Во-первых, заметь это уже не "все", а только те, кто используют
Количество людей, которое может найти баг в исходниках, всяко выше того кол-ва, которое может найти баг в бинарниках. Эти задачи вообще находятся на разных уровнях, не надо ставить их в один ряд.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, kochetkov.vladimir, Вы писали:
V>>А без её наличия желание и умение тебе уже не помогут. KV>Возможность найти уязвимость существует всегда. В отличии от желания и умения.
Я говорил про возможность исправить.
V>>Видимо тесты решили написать? KV>Нет, код впервые за время существования проекта посмотрел тот, кто умел искать уязвимости. После его репорта авторы решили просканировать код каким-то бесплатным анализатором и в пачке обнаруженных еще и им недостатков, как раз и всплыла уязвимость, которой было 23 года.
Тоже вариант. Это как тесты самого кода.
V>>И при чём здесь опен сорс? KV>Не причем. Его защищенность ни чем не лучше защищенности закрытого кода, я только об этом тут и говорю
Это спорно. Защищённость кода в открытых исходниках зависит от степени исапользования его всеми остальными. Открытые библиотеки могут попросту чаще использоваться и соответственно чаще фикситься. А возможность адаптировать исходники под "свои нужны" лишь усиливает это.
V>>есть положительные примеры когда дыры в опенсорсе находили сторонние разработчики. KV>а есть отрицательные, причем прямо в этой и соседней темах Подобное обычно и называют "палка о двух концах", если что.
Ты про 23 года? Это не делает опен сорс хуже по отношению к приватсорсу, это вообще ни о чём ещё не говорит.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, kochetkov.vladimir, Вы писали:
V>>Ты смеёшься чтоли? Кто ж бинари будет анализировать?
KV>Тот, кто имеет навыки реверсинга и анализа защищенности бинарников (тысячи их, просто это не ваши, а наши коллеги)).
а почему бы вашей компании не публиковать исходники своего софта? раз уж она не видит никакой разницы...
Здравствуйте, BulatZiganshin, Вы писали:
KV>>Тот, кто имеет навыки реверсинга и анализа защищенности бинарников (тысячи их, просто это не ваши, а наши коллеги)). BZ>а почему бы вашей компании не публиковать исходники своего софта? раз уж она не видит никакой разницы...
Я только за, но нельзя так просто взять и сломать устоявшийся стереотип у топов, на это нужно время. Уже сейчас есть договоренность с руководством об открытии ряда наших наработок под свободными лицензиями и публикации ключевых алгоритмов в виде научных статей. После этого двинемся дальше — всему свое время.
Здравствуйте, Vain, Вы писали:
V>Количество людей, которое может найти баг в исходниках, всяко выше того кол-ва, которое может найти баг в бинарниках.
Если идти арифметическим путем, то количество тех, кто может найти security-баги блэкбоксом равно сумме и тех и других. А исходники для блэкбокса не требуются. Вот такая занимательная арифметика
V>Эти задачи вообще находятся на разных уровнях, не надо ставить их в один ряд.
Ну не знаю, для кого как. Когда у нас заказывают анализ защищенности, в большинстве случаев доступ к исходникам не предоставляют (чтобы получить более-менее точную картину того, что может сделать реальный потенциальный атакующий). Поэтому как-то приходится в один ряд ставить, уж извини
Здравствуйте, Vain, Вы писали:
V>Здравствуйте, kochetkov.vladimir, Вы писали:
V>>>А без её наличия желание и умение тебе уже не помогут. KV>>Возможность найти уязвимость существует всегда. В отличии от желания и умения. V>Я говорил про возможность исправить.
А я говорил, что пока мы не разберемся с возможностью "найти", рассуждать об еще и "исправить" по меньшей мере странно
V>>>Видимо тесты решили написать? KV>>Нет, код впервые за время существования проекта посмотрел тот, кто умел искать уязвимости. После его репорта авторы решили просканировать код каким-то бесплатным анализатором и в пачке обнаруженных еще и им недостатков, как раз и всплыла уязвимость, которой было 23 года. V>Тоже вариант. Это как тесты самого кода.
Я не об этом. Почему в данном проекте преимущества защищенности opensource-кода не выстрелили в течении 23 лет? Понятно, что частный случай, и правильный ответ на вопрос: "потому что даже его авторы забивали на защищенность, пока их не ткнули носом", но уж больно забавный этот случай)
V>>>И при чём здесь опен сорс? KV>>Не причем. Его защищенность ни чем не лучше защищенности закрытого кода, я только об этом тут и говорю V>Это спорно. Защищённость кода в открытых исходниках зависит от степени исапользования его всеми остальными.
Да, только не защищенность, а заинтересованность того или иного контингента в ее анализе для конкретного продукта. Опыт OpenSSL и X11, правда, говорит об обратном, но ок, допустим соглашусь.
V>Открытые библиотеки могут попросту чаще использоваться и соответственно чаще фикситься. А возможность адаптировать исходники под "свои нужны" лишь усиливает это.
Т.е. увеличивает ту самую защищенность. Что делает открытость исходников лишь одним из множества факторов, потенциально способных повлиять на защищенность продукта при их определенной совокупности. Не более того.
V>Ты про 23 года? Это не делает опен сорс хуже по отношению к приватсорсу, это вообще ни о чём ещё не говорит.
Вот опять ты про свое Я утверждаю "не лучше", почему ты все время пытаешься приписать мне утверждение "хуже"?
Здравствуйте, kochetkov.vladimir, Вы писали:
V>>Эти задачи вообще находятся на разных уровнях, не надо ставить их в один ряд. KV>Ну не знаю, для кого как. Когда у нас заказывают анализ защищенности, в большинстве случаев доступ к исходникам не предоставляют (чтобы получить более-менее точную картину того, что может сделать реальный потенциальный атакующий). Поэтому как-то приходится в один ряд ставить, уж извини
Не понял как недоступность исходников равняет эти вещи.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, kochetkov.vladimir, Вы писали:
V>>>>А без её наличия желание и умение тебе уже не помогут. KV>>>Возможность найти уязвимость существует всегда. В отличии от желания и умения. V>>Я говорил про возможность исправить. KV>А я говорил, что пока мы не разберемся с возможностью "найти", рассуждать об еще и "исправить" по меньшей мере странно
Ты только недавно приводил пример как обычный статик чек исходников находит баги в них и тут же говоришь что не разобрался с возможностью. Да в последнее время только и появляются возможности как через анализ исходников или их линковку с отладочным кодом найти такие баги.
V>>Тоже вариант. Это как тесты самого кода. KV>Я не об этом. Почему в данном проекте преимущества защищенности opensource-кода не выстрелили в течении 23 лет? Понятно, что частный случай, и правильный ответ на вопрос: "потому что даже его авторы забивали на защищенность, пока их не ткнули носом", но уж больно забавный этот случай)
С чего ты взяд что в приватном софте не бывает таких багов? Вот, к примеру, баг с диалоговым окном, которое вешало винду семёрку это скольколетний по-твоему баг?
V>>Открытые библиотеки могут попросту чаще использоваться и соответственно чаще фикситься. А возможность адаптировать исходники под "свои нужны" лишь усиливает это. KV>Т.е. увеличивает ту самую защищенность. Что делает открытость исходников лишь одним из множества факторов, потенциально способных повлиять на защищенность продукта при их определенной совокупности. Не более того.
А это уже само по себе не хорошо?
V>>Ты про 23 года? Это не делает опен сорс хуже по отношению к приватсорсу, это вообще ни о чём ещё не говорит. KV>Вот опять ты про свое Я утверждаю "не лучше", почему ты все время пытаешься приписать мне утверждение "хуже"?
Ты только что выше написал что это фактор из разряда "лучше", не?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
V>Количество людей, которое может найти баг в исходниках, всяко выше того кол-ва, которое может найти баг в бинарниках.
Зато квалификация вторых на порядок выше.
Здравствуйте, CreatorCray, Вы писали:
V>>Количество людей, которое может найти баг в исходниках, всяко выше того кол-ва, которое может найти баг в бинарниках. CC>Зато квалификация вторых на порядок выше.
Но индустрию двигают середнячки, обычные работники, поэтому опять не понятно к чему это сказано.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, CreatorCray, Вы писали: CC>Ну я пару раз выкатывал патчи в виде "offset: bytes заменить на bytes" к чужим бинарям.
Я лично патчил вполне себе закрытый Триллиан (не для секьюрити, а для починки их автодетектора codepage), потому что авторы Триллиана — клинические идиоты. Мало того, что они сами не понимали, что такое интернационализация (это вообще нормально для людей, основной язык которых бинарно одинаков в ASCII7, ASCII, KOI8-R, 866, 20866, 1251, 1252, 1253, UTF8 и ещё в десятке code pages, про которые я ничего не знаю), так они несколько лет последовательно игнорировали письма от более компетентных в вопросе товарищей, где им подробно объясняли, что и где следует починить.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, ins-omnia, Вы писали:
V>>Но индустрию двигают середнячки, обычные работники, поэтому опять не понятно к чему это сказано. IO>Найти нетривиальную уязвимость даже в исходниках — это уровень чуть повыше середнячка.
Для применения всяких статических анализаторов и отладчиков этот уровень ниже среднего.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
V>Для применения всяких статических анализаторов и отладчиков этот уровень ниже среднего.
Вряд ли статические анализаторы нашли бы heartbleed или goto fail.
Проекты вроде OpenSSL и GnuTLS скорее всего регулярно через них прогоняют.
Если не авторы, то кто-то ещё.
Откуда же его [независимый суд] взять, если в нем такие же как мы? (c) VladD2
Здравствуйте, ins-omnia, Вы писали:
V>>Для применения всяких статических анализаторов и отладчиков этот уровень ниже среднего. IO>Вряд ли статические анализаторы нашли бы heartbleed или goto fail. IO>Проекты вроде OpenSSL и GnuTLS скорее всего регулярно через них прогоняют. IO>Если не авторы, то кто-то ещё.
Ну я всякие сложные случаи не рассматриваю. Они и в приватном софте возникают, тут нет ничего особенного. И кстати, для написания тестов, которые находят 95% багов уровень — тоже средний.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
V>Ну я всякие сложные случаи не рассматриваю.
С точки зрения ручного анализа — случаи с heartbleed и openssl были элементарными. А вот статанализатором вещи, подобные задвоенному goto поймать практически нереально в общем случае (см. теорему Райса и рассуждения на тему: http://sgordey.blogspot.ru/2013/07/blog-post_30.html). На практике, результат в 40-60%% обнаруженных анализатором уязвимостей (от числа обнаруженных ручным анализом) дают только наиболее продвинутые решения, выходящие также за рамки статического анализа. Среди свободных анализаторов таких решений в настоящий момент, в общем-то, нет.
V>И кстати, для написания тестов, которые находят 95% багов уровень — тоже средний.
Тесты тут мало чем помогут, ибо баг != уязвимость. Покажи, как ты будешь покрывать тестами подобный этому код, чтобы избежать появления в нем уязвимостей к атакам SQL-инъекций и злоупотребления функционалом. Не хочешь синтетический пример — покажи на примере багов heartbleed и openssl. Или возьми пару любых угроз из какого-нибудь хит-парада типа OWASP TOP 10. Когда начнешь продумывать такие тесты, сам поймешь, насколько они "полезны" в плане обеспечения защищенности кода.
Здравствуйте, Vain, Вы писали:
V>Не понял как недоступность исходников равняет эти вещи.
Я не знаю, на какой еще лад повторить, что анализ бинарников кажется сложным только разработчикам в силу того, что они привыкли работать с исходниками. Понимаешь, среднестатистический разработчик не найдет и половины уязвимостей в коде среднестатистической степени паршивости (неоднократно проверял, в т.ч. здесь), просто потому что это не его предметная область. А для тех, кто этим занимается профессионально, особой разницы нет. В подавляющем же большинстве случаев, при анализе защищенности веб-приложений — и исходники, и бинарники нужны только для того, чтобы выделить в коде вызовы потенциально уязвимых функций, а подтвердить по каждой наличие уязвимости и построить эксплоит (либо опровергнуть ее) проще и быстрее, отправив скриптом пару сотен запросов, чем пол-дня продираться по развеститому CFG, пытаясь вывести ограничения на параметры эксплоита вручную. Блэкбокс реально рулит, а тут пофиг и на исходники, и на бинарники. С поиском и эксплуатацией бинарных уязвимостей в нативных приложениях та же самая история: гораздо проще и быстрее профаззить исследуемое приложение относительно небольшим набором векторов и изучить кейсы, приводящие к крешу под отладчиком, нежели корпеть над кодом, чтобы понять, в какое место относительно стека мы попадаем в каждом конкретном случае.
Здравствуйте, Vain, Вы писали:
KV>>А я говорил, что пока мы не разберемся с возможностью "найти", рассуждать об еще и "исправить" по меньшей мере странно V>Ты только недавно приводил пример как обычный статик чек исходников находит баги в них и тут же говоришь что не разобрался с возможностью.
Я так понимаю, что ты не в курсе существования анализаторов бинарного кода, которые на выходе дают тот же процент обнаруженных уязвимостей, что и анализаторы кода? Ну и блэкбокс-сканеров, которым вообще до лампочки исходники с бинарниками, лишь бы можно было дергать за точки входа в приложение?
Никаких существенных преимуществ при использовании автоматизированных средств, факт наличия исходников не дает. Все равно чуть меньше половины уязвимостей таким образом не обнаружить. А что я думаю по поводу ручного анализа и "возможности" провести его любым желающим — я высказал еще в начале ветки.
V>Да в последнее время только и появляются возможности как через анализ исходников или их линковку с отладочным кодом найти такие баги.
V>С чего ты взяд что в приватном софте не бывает таких багов? Вот, к примеру, баг с диалоговым окном, которое вешало винду семёрку это скольколетний по-твоему баг?
Бывают. Но ты же утверждаешь, что опенсорс де-факто защищеннее. Вот мне и интересно, как в нем даже теоретически может _внезапно_ обнаружиться 23 летний баг, еще и с без малого полутора сотнями менее древних, но не менее критичных?
KV>>Т.е. увеличивает ту самую защищенность. Что делает открытость исходников лишь одним из множества факторов, потенциально способных повлиять на защищенность продукта при их определенной совокупности. Не более того. V>А это уже само по себе не хорошо?
Разумеется хорошо. Я не критикую модель опенсорса, я призываю смотреть на нее объективно и без столмановского фанатизма.
V>Ты только что выше написал что это фактор из разряда "лучше", не?
Но в конечном итоге-то решает совокупность факторов, разве нет?
Здравствуйте, kochetkov.vladimir, Вы писали:
V>>Ты только что выше написал что это фактор из разряда "лучше", не? KV>Но в конечном итоге-то решает совокупность факторов, разве нет?
Для этого должны быть положительные факторы из приват сорса которых нет в открытом. Можешь привести примеры этих факторов?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, ins-omnia, Вы писали:
V>>Для применения всяких статических анализаторов и отладчиков этот уровень ниже среднего. IO>Вряд ли статические анализаторы нашли бы heartbleed или goto fail.
IO>Проекты вроде OpenSSL и GnuTLS скорее всего регулярно через них прогоняют.
Насколько я помню прогонять начали уже после heartbleed
Радует, что по остальным пунктам вопросов уже нет
V>Для этого должны быть положительные факторы из приват сорса которых нет в открытом.
Необязательно. Достаточно чтобы в рамках одного и того же открытого проекта наряду с положительными "сыграли" отрицательные факторы выбранной модели разработки. Например, если целевой аудиторией проекта являются исключительно домохозяйки, то вероятность того, что кто-либо из них заинтересуется возможностью изучить исходный код равна нулю. Туда же она стремиться в малоизвестных проектах с небольшой пользовательской базой, как ты сам заметил выше. А, как уже говорил выше я, обеспечение защищенности кода — процесс, требующий от PM построения и выполнения SDLC (процесса контроля метрик защищенности кода проекта на протяжении всего цикла разработки), в который совершенно не вписывается такой "положительный" фактор, как "кто-нибудь, когда-нибудь — да посмотрит, возможность-то есть". Открытых проектов, в которых этот процесс выстроен: а) эффективно б) на регулярной волонтерской работе, наберется от силы несколько десятков. И это такие проекты, как Debian, NetBSD, Sqlite, NaCl и т.п., т.е. отнюдь не малоизвестные, чья ЦА либо достаточно широка, либо достаточно специфична для того, чтобы в ней нашлись те, кто не только могут, но и умеют, и хотят участвовать в обеспечении защищенности этих проектов.
Здравствуйте, Vain, Вы писали:
V>Конретно ответ был про опенсорс в сравнении с приватным. Поиск уязвимостей никак не связан с открытостью исходников. Но с открытыми исходниками у тебя имеется прямая возможность исправить багу/дыру. Сколько мне раз это надо повторить?
У проектов с закрытыми исходниками обычно есть владелец, который занимается внесением правок в исходный код. Какая принципиальная разница кто исправил баг, ты или владелец продукта ?
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Радует, что по остальным пунктам вопросов уже нет
Я тебя просто перестал понимать, да и времени отвечать на несколько веток нет.
V>>Для этого должны быть положительные факторы из приват сорса которых нет в открытом. KV>Необязательно. Достаточно чтобы в рамках одного и того же открытого проекта наряду с положительными "сыграли" отрицательные факторы выбранной модели разработки.
Отрицательные факторы ничего не будут говорить потому-что они присутствуют везде. Меряют по кол-ву плюшек а не г-на.
KV>Например, если целевой аудиторией проекта являются исключительно домохозяйки, то вероятность того, что кто-либо из них заинтересуется возможностью изучить исходный код равна нулю.
Я работаю в программировании давно и домохозяек здесь ни одной не видел.
KV>Туда же она стремиться в малоизвестных проектах с небольшой пользовательской базой, как ты сам заметил выше. А, как уже говорил выше я, обеспечение защищенности кода — процесс, требующий от PM построения и выполнения SDLC (процесса контроля метрик защищенности кода проекта на протяжении всего цикла разработки), в который совершенно не вписывается такой "положительный" фактор, как "кто-нибудь, когда-нибудь — да посмотрит, возможность-то есть".
Да это просто не решаемая задача в рамках пм-а. Всё равно будут дыры.
KV>Открытых проектов, в которых этот процесс выстроен: а) эффективно б) на регулярной волонтерской работе, наберется от силы несколько десятков. И это такие проекты, как Debian, NetBSD, Sqlite, NaCl и т.п., т.е. отнюдь не малоизвестные, чья ЦА либо достаточно широка, либо достаточно специфична для того, чтобы в ней нашлись те, кто не только могут, но и умеют, и хотят участвовать в обеспечении защищенности этих проектов.
У этих проектов и аудитория не маленькая, так? Мне почему-то кажется что именно этот фактор накладывает свой отпечаток на защищённость.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Evgeniy Skvortsov, Вы писали:
V>>Конретно ответ был про опенсорс в сравнении с приватным. Поиск уязвимостей никак не связан с открытостью исходников. Но с открытыми исходниками у тебя имеется прямая возможность исправить багу/дыру. Сколько мне раз это надо повторить? ES>У проектов с закрытыми исходниками обычно есть владелец, который занимается внесением правок в исходный код. Какая принципиальная разница кто исправил баг, ты или владелец продукта ?
Огромная разница. Для того чтобы владелец исправил — ему надо захотеть сделать это. И вот тут появляется 100500 причин почему не надо это делать. К примеру, "продукт и так деньги приносит", "нету времени мы пилим новые фичи", "новая версия не содержит этого бага — фича для покупки новой версии", "новая исправленная версия не поддерживается фичи X — устарела, а пользователи всё-равно пользуют", "дыра не страшная — мы не тот продукт чтобы её закрывать".
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, ins-omnia, Вы писали:
IO>Вряд ли статические анализаторы нашли бы heartbleed или goto fail.
Подробные комментарии от авторов Coverity на эту тему в ветке уже обсуждались. Имхо, они гораздо убедительнее, чем абстрактное "вряд ли", основанное на отсутствии информации.
IO>Проекты вроде OpenSSL и GnuTLS скорее всего регулярно через них прогоняют.
На протяжении всего топика единственный компетентный в теме человек с ангельским терпением пытается опровергнуть это ваше беспочвенное предположение при помощи фактов. IO>Если не авторы, то кто-то ещё.
Вы опять повторяете мантру "из тысяч глаз кто-то да увидит", несмотря на её ошибочность, обоснованную теоретически и подтверждённую экспериментом. Зачем?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Vain, Вы писали: V>Огромная разница. Для того чтобы владелец исправил — ему надо захотеть сделать это. И вот тут появляется 100500 причин почему не надо это делать. К примеру, "продукт и так деньги приносит", "нету времени мы пилим новые фичи", "новая версия не содержит этого бага — фича для покупки новой версии", "новая исправленная версия не поддерживается фичи X — устарела, а пользователи всё-равно пользуют", "дыра не страшная — мы не тот продукт чтобы её закрывать".
И всё перевешивает ровно одна причина: коммерческий ущерб от уязвимости.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
V>>Огромная разница. Для того чтобы владелец исправил — ему надо захотеть сделать это. И вот тут появляется 100500 причин почему не надо это делать. К примеру, "продукт и так деньги приносит", "нету времени мы пилим новые фичи", "новая версия не содержит этого бага — фича для покупки новой версии", "новая исправленная версия не поддерживается фичи X — устарела, а пользователи всё-равно пользуют", "дыра не страшная — мы не тот продукт чтобы её закрывать". S>И всё перевешивает ровно одна причина: коммерческий ущерб от уязвимости.
Пример можно таких ущербов?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Sinclair, Вы писали:
IO>>Вряд ли статические анализаторы нашли бы heartbleed или goto fail. S>Подробные комментарии от авторов Coverity на эту тему в ветке уже обсуждались. Имхо, они гораздо убедительнее, чем абстрактное "вряд ли", основанное на отсутствии информации.
Именно в этой теме? Не нашел.
IO>>Проекты вроде OpenSSL и GnuTLS скорее всего регулярно через них прогоняют. S>На протяжении всего топика единственный компетентный в теме человек с ангельским терпением пытается опровергнуть это ваше беспочвенное предположение при помощи фактов.
Ещё раз просмотрел тему. О применении статических анализаторов к этим проектам речи тут не шло. Как и о применимости статических анализаторов
к обсуждаемым недавним уязвимостям. Можно ссылку?
S>Вы опять повторяете мантру "из тысяч глаз кто-то да увидит", несмотря на её ошибочность, обоснованную теоретически и подтверждённую экспериментом. Зачем?
Я как раз не сторонник этого лозунга. Это очевидная чушь. На сегодняшний день известны уязвимости в широко используемом софте, которые жили несколько десятилетий, тут heartbleed отдыхает.
Собственно смысл моего комментария прямо противоположный.
Откуда же его [независимый суд] взять, если в нем такие же как мы? (c) VladD2
Здравствуйте, Vain, Вы писали:
KV>>Радует, что по остальным пунктам вопросов уже нет V>Я тебя просто перестал понимать, да и времени отвечать на несколько веток нет.
Первое легко решить, уточнив у меня все непонятные моменты и утвержедния
KV>>Необязательно. Достаточно чтобы в рамках одного и того же открытого проекта наряду с положительными "сыграли" отрицательные факторы выбранной модели разработки. V>Отрицательные факторы ничего не будут говорить потому-что они присутствуют везде. Меряют по кол-ву плюшек а не г-на.
Мне неизвестны проекты (ни закрытые, ни открытые) где целенаправленно бы рассматривались положительные метрики, но при этом игнорировались отрицательные.
KV>>Например, если целевой аудиторией проекта являются исключительно домохозяйки, то вероятность того, что кто-либо из них заинтересуется возможностью изучить исходный код равна нулю. V>Я работаю в программировании давно и домохозяек здесь ни одной не видел.
Я вообще не об этом, а о том, что для открытого проекта веб-сервиса рассчета критических дней вероятность того, что среди его аудитории найдется тот(та?), кто будет способен находить и исправлять баги защищенности на порядок ниже, чем у не менее открытого проекта веб-сервиса REPL популярных языков.
V>Да это просто не решаемая задача в рамках пм-а.
Просто интересно, а в рамках кого (на твой взгляд) должна решаться задача по обеспечению защищенности разрабатываемого в проекте кода?
V>Всё равно будут дыры.
Разумеется будут, как и любой другой класс багов. Не совсем понял, как это утверждение относится к обсуждаемой теме?
KV>>Открытых проектов, в которых этот процесс выстроен: а) эффективно б) на регулярной волонтерской работе, наберется от силы несколько десятков. И это такие проекты, как Debian, NetBSD, Sqlite, NaCl и т.п., т.е. отнюдь не малоизвестные, чья ЦА либо достаточно широка, либо достаточно специфична для того, чтобы в ней нашлись те, кто не только могут, но и умеют, и хотят участвовать в обеспечении защищенности этих проектов. V>У этих проектов и аудитория не маленькая, так? Мне почему-то кажется что именно этот фактор накладывает свой отпечаток на защищённость.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Я вообще не об этом, а о том, что для открытого проекта веб-сервиса рассчета критических дней вероятность того, что среди его аудитории найдется тот(та?), кто будет способен находить и исправлять баги защищенности на порядок ниже, чем у не менее открытого проекта веб-сервиса REPL популярных языков.
Здравствуйте, Vain, Вы писали: S>>И всё перевешивает ровно одна причина: коммерческий ущерб от уязвимости. V>Пример можно таких ущербов?
Например, партнёр, использующий ваш софт, внезапно заявляет вашей компании, что в этом году платить лицензионные отчисления не будет, т.к. допущенная вами уязвимость стоила ему бразиллион репутационного ущерба.
Отсудить сам ущерб, понятное дело, он не может. Потому что EULA, this software is provided "as is" и всё такое. А вот отказаться платить — запросто. И у вас план по recurring revenue проседает. А если вы продолжите в том же духе, то таких партнёров станет больше, а потом и новые сделки внезапно перестанут подписываться, потому что your attitude to the security is well known on the market.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>>Радует, что по остальным пунктам вопросов уже нет V>>Я тебя просто перестал понимать, да и времени отвечать на несколько веток нет. KV>Первое легко решить, уточнив у меня все непонятные моменты и утвержедния
Да нет, ты не понял. Я вижу что тебя просто не переубедить. Ты считаешь что открытость софта не влияет на его защищённость — ok.
KV>>>Необязательно. Достаточно чтобы в рамках одного и того же открытого проекта наряду с положительными "сыграли" отрицательные факторы выбранной модели разработки. V>>Отрицательные факторы ничего не будут говорить потому-что они присутствуют везде. Меряют по кол-ву плюшек а не г-на. KV>Мне неизвестны проекты (ни закрытые, ни открытые) где целенаправленно бы рассматривались положительные метрики, но при этом игнорировались отрицательные.
Отрицательные не игнорируются. Их не имеет смысла рассматривать. Открытый софт это тот же закрытый, только ещё исходники в общем доступе, вот и всего. Как видишь, здесь минусов, как минимум, поровну.
KV>>>Например, если целевой аудиторией проекта являются исключительно домохозяйки, то вероятность того, что кто-либо из них заинтересуется возможностью изучить исходный код равна нулю. V>>Я работаю в программировании давно и домохозяек здесь ни одной не видел. KV>Я вообще не об этом, а о том, что для открытого проекта веб-сервиса рассчета критических дней вероятность того, что среди его аудитории найдется тот(та?), кто будет способен находить и исправлять баги защищенности на порядок ниже, чем у не менее открытого проекта веб-сервиса REPL популярных языков.
Ещё раз. Тот кто использует и имеет желание исправить/кинуть патч — сделает это. Или просто укажет на дыру и её исправит уже мейнтейнер, что более вероятно.
V>>Да это просто не решаемая задача в рамках пм-а. KV>Просто интересно, а в рамках кого (на твой взгляд) должна решаться задача по обеспечению защищенности разрабатываемого в проекте кода?
Как минимум тех.специалиста в этом, а не какого-то пм-а.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, kochetkov.vladimir, Вы писали:
... KV>Просто интересно, а в рамках кого (на твой взгляд) должна решаться задача по обеспечению защищенности разрабатываемого в проекте кода?
влезу я со своими 5 копеек. в одной "маленькой" корпорации игропрома есть специальное подразделение из инженеров. Как только продуктовая тима делает нечто, что будет в дикой природе взаимодействовать с дикими юзверями, например прием крешдампов от населения. Так сразу появляется "секьюрити аудит". Причем их больше волнуют серверы/сервисы. На клиентской стороне часто достаточно нечто обернуть в какую-нибудь покупную (одобренную ими) же гадость типа вмпротекта. Так что в доморощенный аудит в команде из 15 человек я как-то не верю.
Около трети вроде бы, если поточнее: http://w3techs.com/technologies/overview/operating_system/all 
ибо был на 1.0.0.
Код не статичем (если мы не об уже мертвом проекте, конечно), он меняется с каждым коммитом. С каждым коммитом количество уязвимостей в нем может как увеличиваться, так и уменьшаться. Именно поэтому модель обеспечения защищенноти "кто-нибудь, когда-нибудь, один раз посмотрит и может быть найдет уявзимость" — попросту не работает. Также, как и если после проведения аудита, авторами truecrypt не будет налажен SDLC, то собранные сообществом деньги окажется выброшенными на ветер, в общем-то.
Почему heartbleed просуществовал в openssl около 2 лет, если его код использовался в подавляющем большинстве аппаратных файрволов и роутеров? 
), я имею ввиду именно участие по поиску и устранению уязвимостей.
Я утверждаю "не лучше", почему ты все время пытаешься приписать мне утверждение "хуже"?
