Здравствуйте, 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 человек я как-то не верю.
