Здравствуйте, Yoriсk, Вы писали:

IO>>>Собственно баги в бинарном проприетарном софте находят постоянно. Это рутина вообще-то.
V>>А толку то от того что ты найдёшь? Как ты его пофиксишь то?
Y>Пишешь вендору, он фиксит.
Пишешь вендору — он не фиксит. Далнейшие действия?

Y>Или не пишешь и тихоноко эксплуатируешь уязвимость.
Y>Как в опенсорс примерно.
Мимо. Как и ВЕЗДЕ.

Здравствуйте, Evgeniy Skvortsov, Вы писали:

V>>Ты зря дурака включил
ES>имхо, дурака включил как раз ты, причем намного раньше по ветке.
Конретно ответ был про опенсорс в сравнении с приватным. Поиск уязвимостей никак не связан с открытостью исходников. Но с открытыми исходниками у тебя имеется прямая возможность исправить багу/дыру. Сколько мне раз это надо повторить?

Здравствуйте, Vain, Вы писали:

IO>>>>Собственно баги в бинарном проприетарном софте находят постоянно. Это рутина вообще-то.
V>>>А толку то от того что ты найдёшь? Как ты его пофиксишь то?
Y>>Пишешь вендору, он фиксит.
V>Пишешь вендору — он не фиксит. Далнейшие действия?
Да то же самое что и в опенсурсе — грустить.
Баг найти это одно, правильно починить ничего не сломав — сильно другое.
Особенно в security critical code, особенно в такой помойке как сурсы OpenSSL.

Здравствуйте, Vain, Вы писали:
...
V>Конретно ответ был про опенсорс в сравнении с приватным. Поиск уязвимостей никак не связан с открытостью исходников. Но с открытыми исходниками у тебя имеется прямая возможность исправить багу/дыру. Сколько мне раз это надо повторить?
повторять не надо — достаточно хранить историю успешно исправленных в опенсорсе дыр и при случае ею хвастаться. а до тех пор это все потенциальные возможности исправить, до которых дела никому нет.

Здравствуйте, CreatorCray, Вы писали:

V>>Пишешь вендору — он не фиксит. Далнейшие действия?
CC>Да то же самое что и в опенсурсе — грустить.

А вот и не то же. В опесорсе ты пишешь патч (благо для дыр в безопасности они обычно маленькие),
компилируешь пакет для своего дистрибутива и забывыешь о проблеме. Или скорее всего это делает мантейнер
пакета для твоего дистрибутива.
А в проприетарщине ты не грустишь, а идешь на ч0рный рынок продавать зеродей.

Здравствуйте, CreatorCray, Вы писали:

CC>Да то же самое что и в опенсурсе — грустить.
У вас в опенсорсе зудит что вы его так не любите? Это не тоже самое, потому-что не эквивалентно.

CC>Баг найти это одно, правильно починить ничего не сломав — сильно другое.
CC>Особенно в security critical code, особенно в такой помойке как сурсы OpenSSL.
Это не объясняет того, что этого нельзя сделать.

Здравствуйте, SleepyDrago, Вы писали:

SD>...
V>>Конретно ответ был про опенсорс в сравнении с приватным. Поиск уязвимостей никак не связан с открытостью исходников. Но с открытыми исходниками у тебя имеется прямая возможность исправить багу/дыру. Сколько мне раз это надо повторить?
SD>повторять не надо — достаточно хранить историю успешно исправленных в опенсорсе дыр и при случае ею хвастаться. а до тех пор это все потенциальные возможности исправить, до которых дела никому нет.
Не надо за всех говорить. Я лично находил и исправлял в SISL'е баги. Софт был куплен, но и открыт под GPL.

Здравствуйте, 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>Сделать то можно, вопрос в требуемых усилиях.
Тому кому надо, прилагает ровно столько же усилий, сколько прилагает и к приватному софту.

Здравствуйте, Vain, Вы писали:

V>Это не потому то ли что ты его можешь видеть за бесплатно?
Нет.

CC>>Очень мало проектов в которых наведена дисциплина и код пишут и комментируют согласно единому и вменяемому стандарту.
V>Это что за стандарт такой — вменяемый?
Это который логичен и обоснован.

Здравствуйте, CreatorCray, Вы писали:

V>>Это не потому то ли что ты его можешь видеть за бесплатно?
CC>Нет.
Отрицаешь очевидное?

CC>>>Очень мало проектов в которых наведена дисциплина и код пишут и комментируют согласно единому и вменяемому стандарту.
V>>Это что за стандарт такой — вменяемый?
CC>Это который логичен и обоснован.
Какой из 100500 логичных и обоснованных?

Здравствуйте, CreatorCray, Вы писали:

IO>>А вот и не то же. В опесорсе ты пишешь патч (благо для дыр в безопасности они обычно маленькие),
IO>>компилируешь пакет для своего дистрибутива и забывыешь о проблеме.
CC>Или получаешь проблему ещё больше, потому как не учёл какой либо аспект.
В сравнении с проприетарным это проблема вообще никакая, это аспект потом правиться также.

Здравствуйте, 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>Тот кто пользует код из опенсорса тот и отсылает патчи/фиксы.
Во-первых, заметь это уже не "все", а только те, кто используют

Количество людей, которое может найти баг в исходниках, всяко выше того кол-ва, которое может найти баг в бинарниках. Эти задачи вообще находятся на разных уровнях, не надо ставить их в один ряд.

Здравствуйте, kochetkov.vladimir, Вы писали:

V>>А без её наличия желание и умение тебе уже не помогут.
KV>Возможность найти уязвимость существует всегда. В отличии от желания и умения.
Я говорил про возможность исправить.

V>>Видимо тесты решили написать?
KV>Нет, код впервые за время существования проекта посмотрел тот, кто умел искать уязвимости. После его репорта авторы решили просканировать код каким-то бесплатным анализатором и в пачке обнаруженных еще и им недостатков, как раз и всплыла уязвимость, которой было 23 года.
Тоже вариант. Это как тесты самого кода.

V>>И при чём здесь опен сорс?
KV>Не причем. Его защищенность ни чем не лучше защищенности закрытого кода, я только об этом тут и говорю
Это спорно. Защищённость кода в открытых исходниках зависит от степени исапользования его всеми остальными. Открытые библиотеки могут попросту чаще использоваться и соответственно чаще фикситься. А возможность адаптировать исходники под "свои нужны" лишь усиливает это.

V>>есть положительные примеры когда дыры в опенсорсе находили сторонние разработчики.
KV>а есть отрицательные, причем прямо в этой и соседней темах Подобное обычно и называют "палка о двух концах", если что.
Ты про 23 года? Это не делает опен сорс хуже по отношению к приватсорсу, это вообще ни о чём ещё не говорит.

Здравствуйте, kochetkov.vladimir, Вы писали:

V>>Ты смеёшься чтоли? Кто ж бинари будет анализировать?

KV>Тот, кто имеет навыки реверсинга и анализа защищенности бинарников (тысячи их, просто это не ваши, а наши коллеги)).

а почему бы вашей компании не публиковать исходники своего софта? раз уж она не видит никакой разницы...

Здравствуйте, BulatZiganshin, Вы писали:

KV>>Тот, кто имеет навыки реверсинга и анализа защищенности бинарников (тысячи их, просто это не ваши, а наши коллеги)).
BZ>а почему бы вашей компании не публиковать исходники своего софта? раз уж она не видит никакой разницы...

Я только за, но нельзя так просто взять и сломать устоявшийся стереотип у топов, на это нужно время. Уже сейчас есть договоренность с руководством об открытии ряда наших наработок под свободными лицензиями и публикации ключевых алгоритмов в виде научных статей. После этого двинемся дальше — всему свое время.