Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 107
Думаю публиковать уязвимости надо, это будим стимулом для разработчиков как можно быстрее и качественнее исправлять и дорабатывать свой продукт.
Но параллельно с публикацией отправлять инфу об уязвимости в саппорт было бы тоже хорошо. =)
Но параллельно с публикацией отправлять инфу об уязвимости в саппорт было бы тоже хорошо. =)
Вот. Письмо в саппорт, через сутки публикация. Надо учитывать что люди в разных часовых поясах живут, зачастую не в стране-представителе компании.
Сутки что то мало совсем. Обычно, поле нахождения уязвимости, оправляется письмо о нахождении уязвимости, на что она влияет. И попросить ответить на это письмо, разные фирмы бывают. Потом проходит некоторое время и если ничего не происходит, или компания отказалась от этого предложения, считая его малозначительным, уязвимость публикуется в общий доступ. И уж тогда они никуда не денутся, залатают дырку. Неплохо бы, ещё, прикрыться какой нибудь организацией, которая специализируется на ИБ, иначе можно и огрести:)
Поэтому — трое. День на разницу поясов. День на разбор полётов. И день на реакцию. По-моему, достаточно, чтобы определиться и как-то ответить. Хотя бы письменно.
То есть Вы считаете что закрытие баги в коде — это самоцель?
А пользователям не хотите дать время на обновление? Или они все сидят на «низком старте» в ожидании нового релиза?
А пользователям не хотите дать время на обновление? Или они все сидят на «низком старте» в ожидании нового релиза?
5 — +2 дня на выходные :)
Судя по комментариям, в вашей голове разработка приложения для себя на коленке и производственный процесс крупного софта — это одно и то же.
Представьте крупный продукт, у которого миллионы пользователей, они найдут любую ошибку с гораздо большей вероятностью чем группа тестирования любой квалификации и размера.
Написать эксплоит к найденной баге в крупном продукте часто может быть проще чем багу протестировать, передать в разработку, включить в билды, провести регрессионное тестирование и что не менее, а возможно и более важно провести внедрение.
Стоимость внедрения исправления у вас не рассматривается ни в заметке, ни в комментариях. Очень часто она очень высока, а в исключительных случаях внедрение невозможно вовсе (подумайте как бы вы исправляли баги в ПО баллистической ракеты или марсохода после их запуска).
Прежде чем с таким максимализмом судить компании («это рынок, детка») загляните например в багтрекеры свободного популярного ПО. Зачастую там тысячи неисправленных записей.
Представьте крупный продукт, у которого миллионы пользователей, они найдут любую ошибку с гораздо большей вероятностью чем группа тестирования любой квалификации и размера.
Написать эксплоит к найденной баге в крупном продукте часто может быть проще чем багу протестировать, передать в разработку, включить в билды, провести регрессионное тестирование и что не менее, а возможно и более важно провести внедрение.
Стоимость внедрения исправления у вас не рассматривается ни в заметке, ни в комментариях. Очень часто она очень высока, а в исключительных случаях внедрение невозможно вовсе (подумайте как бы вы исправляли баги в ПО баллистической ракеты или марсохода после их запуска).
Прежде чем с таким максимализмом судить компании («это рынок, детка») загляните например в багтрекеры свободного популярного ПО. Зачастую там тысячи неисправленных записей.
Вот вопрос — какое «определённое» время? Мне лично была заявлена абсолютно безбожная цифра «не меньше трёх недель».
Если продукт популярен — то у «одиночки» должно хватать ресурсов для его быстрого исправления. Если это платная программа — нанимаются дополнительные специалисты. Если open-source — популярность привлекает внимание.
Я уже не говорю о корпорациях.
Дифференциация сроков для «одиночек» и «корпораций» просто стимулирует или корпоративное производство софта, или индивидуальное. Мне, как пользователю, без разницы, кто автор — Microsoft или Вася Пупкин, я хочу стабильную и надёжную работу.
Я уже не говорю о корпорациях.
Дифференциация сроков для «одиночек» и «корпораций» просто стимулирует или корпоративное производство софта, или индивидуальное. Мне, как пользователю, без разницы, кто автор — Microsoft или Вася Пупкин, я хочу стабильную и надёжную работу.
За 3 дня доп специалиста не наймете. А держать «на всякий случай» — тоже экономически необоснованно.
Не знаю почему вы хотите давать всего 3 дня и создавать напряженность у производителя (потому как и за 3 дня компания может не успеть залатать дыру и распространить апдейт), но не согласен с таким подходом.
А вообще в той же статье в вики en.wikipedia.org/wiki/Responsible_disclosure
перечислен список более менее популярных уязвимостей прошедших через RD:
Security vulnerabilities resolved by applying responsible disclosure:
Что то я ни одной не вижу за 3 дня.
Зато я вполне понимаю зачем именно нужен короткий срок — коммерциализация и монетизация уязвимостей в преступной среде вполне набирает обороты.
Так что давайте сначала определимся — вы в белой или в черной шляпе-то?
Не знаю почему вы хотите давать всего 3 дня и создавать напряженность у производителя (потому как и за 3 дня компания может не успеть залатать дыру и распространить апдейт), но не согласен с таким подходом.
А вообще в той же статье в вики en.wikipedia.org/wiki/Responsible_disclosure
перечислен список более менее популярных уязвимостей прошедших через RD:
Security vulnerabilities resolved by applying responsible disclosure:
- Dan Kaminsky discovery of DNS cache poisoning, 5 months
- Radboud University Nijmegen breaks the security of the MIFARE Classic cards, 6 months
- MBTA vs. Anderson, MIT students find vulnerability in the Massachusetts subway security, 5 months
- MD5 collision attack that shows how to create false CA certificates, 1 week
Что то я ни одной не вижу за 3 дня.
Зато я вполне понимаю зачем именно нужен короткий срок — коммерциализация и монетизация уязвимостей в преступной среде вполне набирает обороты.
Так что давайте сначала определимся — вы в белой или в черной шляпе-то?
Если разработчик занимается фигнёй, в результате чего в его продукте находят каждый день по куче ошибок, а устранять их он или не спешит или не имеет возможности — такой продукт будет непопулярен, и продать эксплоиты для него будет попросту невыгодно — кому они нужны?
P.S. Я в закрытых помещениях шляпы не ношу ;)
P.S. Я в закрытых помещениях шляпы не ношу ;)
Извините, но это демагогия. Ваш вопрос звучал о том, как поступать «хакеру» а не о том — что хакер должен измышлять о труде разработчика.
К тому же фраза про непопулярный из-за уязвимостей продукт — не больше чем иллюзии (или целенаправленное вранье) — наиболее популярные продукты — наиболее уязвимые. И именно из-за популярности:
Adobe(Acrobat) Reader, Adobe Flash, Microsoft IE6.
Достаточное количество уязвимостей находят и в набирающем популярность Firefox (просто стоит почитать Patch history, чтобы в этом убедиться). Да, в последнем продукте они быстро патчатся, честь и хвала. Но это не имеет никакого отношения к коэффициенту популярность\уязвимость.
И все это очень даже продается.
А насчет шляпы — Вы прекрасно поняли о чем я хотел сказать, просто трудно признаться себе и общественности что этот разговор нужен больше для оправдания (под прикрытием «общественного мнения») «неэтичного» поведения, а не для того чтобы принять какое-то решение. Из Вашего мнения про три дня вполне четко видно что для себя вы решение уже почти приняли, просто хочется как-то его аморальность затереть среди мнений толпы. А зачем?
К тому же фраза про непопулярный из-за уязвимостей продукт — не больше чем иллюзии (или целенаправленное вранье) — наиболее популярные продукты — наиболее уязвимые. И именно из-за популярности:
Adobe(Acrobat) Reader, Adobe Flash, Microsoft IE6.
Достаточное количество уязвимостей находят и в набирающем популярность Firefox (просто стоит почитать Patch history, чтобы в этом убедиться). Да, в последнем продукте они быстро патчатся, честь и хвала. Но это не имеет никакого отношения к коэффициенту популярность\уязвимость.
И все это очень даже продается.
А насчет шляпы — Вы прекрасно поняли о чем я хотел сказать, просто трудно признаться себе и общественности что этот разговор нужен больше для оправдания (под прикрытием «общественного мнения») «неэтичного» поведения, а не для того чтобы принять какое-то решение. Из Вашего мнения про три дня вполне четко видно что для себя вы решение уже почти приняли, просто хочется как-то его аморальность затереть среди мнений толпы. А зачем?
Где слово «хакер»? Давайте обыграем пользователя ПО, который честно заплатил за лицензию, нашёл баг — и техподдержка ему мусолит мозги приблизительно с год, заявляя, что «Ваш баг имеет низкий приоритет»? Им плевать на то, что продукт не выполняет заявленного — просто «задача Вашу узко специализирована, а мы заняты более важными проблемами».
И кого в этом случае оставили в шляпе? ;)
Растущая популярность Firefox (который, кстати, не продаётся) частично обусловлена именно быстрой реакцией на уязвимости. А Microsoft IE6 используется только самоубийцами, поскольку дыряв, как решето — уж лучше IE7.
Чем пытаться вывести меня на чистую воду и рассмотреть цвет моей одежды, потрудитесь хотя бы приводить примеры подостойнее.
И давайте уйдём от браузеров, ОС. Есть и другие примеры: антивирусы, офисные программы. Поговорим? ;)
И кого в этом случае оставили в шляпе? ;)
Растущая популярность Firefox (который, кстати, не продаётся) частично обусловлена именно быстрой реакцией на уязвимости. А Microsoft IE6 используется только самоубийцами, поскольку дыряв, как решето — уж лучше IE7.
Чем пытаться вывести меня на чистую воду и рассмотреть цвет моей одежды, потрудитесь хотя бы приводить примеры подостойнее.
И давайте уйдём от браузеров, ОС. Есть и другие примеры: антивирусы, офисные программы. Поговорим? ;)
А в чем примеры недостойны? Ну флэш и адоб ридер тоже не продаются. А IE — бесплатен, просто работает только на платформе Win.
Не вижу принципиальной разницы в отношении «продаваемости», обоснуйте претензии по недостойности примеров. И также не вижу смысла уходить на какое-то более удобное поле — говорим об уязвимостях в общем — значит в общем.
Если у вас есть примеры сравнимых по популярности (не в процентном отношении, типа «80% пользователей FreeBSD 9.0 пользуются продуктом Х», а в абсолютном, пусть и приблизительном количестве пользователей), но «неуязвимых» продуктов — приводите. Мне даже не принципиально будет ли это OS или антивирус или офисная программа. Просто вектор атаки обычно направлен на определенные «удобные» категории программ, например раньше, в период популярности desktop mail-клиентов — атаковали через email. Теперь этот вектор малоиспользуемый, и не потому что уязвимостей меньше, потому что неинтересно уже так атаковать.
К тому же мои примеры были не только в отношении браузеров, 50% примеров — не браузеры, читайте внимательней, пожалуйста. Кто и как использует IE6 или любой другой продукт — тоже не относится к делу. Используют далеко не всегда по незнанию, часто бывает несовместимость с каким-то древним приложением или другие, независящие от пользователя условия.
И на тему года мусоления — год с момента обращения это год, это не три дня. Этот пример также не подходит под заданный вопрос. Если действительно год мусолят, после честного Responsible Disclosure — даже вопрос не имеет смысла — публиковать, с подтверждением, что обращались и описывали все честно. Поставлю честный плюс даже если это продукт компании, в которой я работаю.
Не вижу принципиальной разницы в отношении «продаваемости», обоснуйте претензии по недостойности примеров. И также не вижу смысла уходить на какое-то более удобное поле — говорим об уязвимостях в общем — значит в общем.
Если у вас есть примеры сравнимых по популярности (не в процентном отношении, типа «80% пользователей FreeBSD 9.0 пользуются продуктом Х», а в абсолютном, пусть и приблизительном количестве пользователей), но «неуязвимых» продуктов — приводите. Мне даже не принципиально будет ли это OS или антивирус или офисная программа. Просто вектор атаки обычно направлен на определенные «удобные» категории программ, например раньше, в период популярности desktop mail-клиентов — атаковали через email. Теперь этот вектор малоиспользуемый, и не потому что уязвимостей меньше, потому что неинтересно уже так атаковать.
К тому же мои примеры были не только в отношении браузеров, 50% примеров — не браузеры, читайте внимательней, пожалуйста. Кто и как использует IE6 или любой другой продукт — тоже не относится к делу. Используют далеко не всегда по незнанию, часто бывает несовместимость с каким-то древним приложением или другие, независящие от пользователя условия.
И на тему года мусоления — год с момента обращения это год, это не три дня. Этот пример также не подходит под заданный вопрос. Если действительно год мусолят, после честного Responsible Disclosure — даже вопрос не имеет смысла — публиковать, с подтверждением, что обращались и описывали все честно. Поставлю честный плюс даже если это продукт компании, в которой я работаю.
Ну ОК, раз меня упрекают в голословности — потом не упрекайте в начале холивара.
Kaspersky Internet Security. Нерабочая кнопка антиспама в Outlook Express. Номер заявки в техподдержку и вспоминать не буду — было в пору 2009-й версии. После повторения в 2010-й версии вопрос о продолжении лицензионных отношений с Kaspersky Lab был решён.
Жду плюса ;) Хотя исходно история начиналась совершенно не об этом. Вы сами настояли.
Kaspersky Internet Security. Нерабочая кнопка антиспама в Outlook Express. Номер заявки в техподдержку и вспоминать не буду — было в пору 2009-й версии. После повторения в 2010-й версии вопрос о продолжении лицензионных отношений с Kaspersky Lab был решён.
Жду плюса ;) Хотя исходно история начиналась совершенно не об этом. Вы сами настояли.
Это уязвимость?
А уязвимость которого из перечисленных продуктов?
Эту уязвимость можно эксплуатировать чтобы нарушить работу продукта?
Какой вектор атаки позволяет осуществить данная уязвимость?
Какие условия эксплуатации этой уязвимости?
Вы это описали и отправилив касперский?
Я понимаю что вы сильно обиделись на Касперского за то, что они не исправили этот баг, но в реальности баг и уязвимость продукта — совершенно разные вещи. Уязвимость Касперского это, например, возможность сформировать такое письмо, которое при открытии в Outlook Express при неработоспособной кнопке(модуле) Касперского вызывает прекращение работы Касперского вообще, или рушит ОС пользователя, или позволяет выполнить произвольный код с правами админа или текущего пользователя. А вот если бы кнопка касперского работала — этого бы добиться было нельзя. Вот как примерно выглядит из себя «уязвимость» Касперского.
Вы же описали просто «баг функционала». Он вряд ли влияет на работоспособность самого продукта, как системы защиты. Да, это недоработка не позволяет «тренировать» касперского на спам и он хуже справляется с обещанными и оплаченными функциями. Но это никак не уязвимость продукта, нарушающая его функциональность, это баг, не позволяющий расширить набор фильтров для проверки на спам.
К тому же если погуглить — есть некоторое решение —
forum.kaspersky.com/index.php?showtopic=162041&st=0&p=1298624&#entry1298624
Вы его пробовали? Не помогло?
Я кстати опять же не понимаю в чем состоит страшное открытие этой уязвимости — публичные форумы заполненны сообщениями о том что есть такая проблема.
Dixi.
А уязвимость которого из перечисленных продуктов?
Эту уязвимость можно эксплуатировать чтобы нарушить работу продукта?
Какой вектор атаки позволяет осуществить данная уязвимость?
Какие условия эксплуатации этой уязвимости?
Вы это описали и отправилив касперский?
Я понимаю что вы сильно обиделись на Касперского за то, что они не исправили этот баг, но в реальности баг и уязвимость продукта — совершенно разные вещи. Уязвимость Касперского это, например, возможность сформировать такое письмо, которое при открытии в Outlook Express при неработоспособной кнопке(модуле) Касперского вызывает прекращение работы Касперского вообще, или рушит ОС пользователя, или позволяет выполнить произвольный код с правами админа или текущего пользователя. А вот если бы кнопка касперского работала — этого бы добиться было нельзя. Вот как примерно выглядит из себя «уязвимость» Касперского.
Вы же описали просто «баг функционала». Он вряд ли влияет на работоспособность самого продукта, как системы защиты. Да, это недоработка не позволяет «тренировать» касперского на спам и он хуже справляется с обещанными и оплаченными функциями. Но это никак не уязвимость продукта, нарушающая его функциональность, это баг, не позволяющий расширить набор фильтров для проверки на спам.
К тому же если погуглить — есть некоторое решение —
forum.kaspersky.com/index.php?showtopic=162041&st=0&p=1298624&#entry1298624
Вы его пробовали? Не помогло?
Я кстати опять же не понимаю в чем состоит страшное открытие этой уязвимости — публичные форумы заполненны сообщениями о том что есть такая проблема.
Dixi.
А какая мне разница, как это называется, если программа, за которую я заплатил деньги, не выполняет заявленные функции? Обращение было через личный кабинет, а не через форум — в тот момент я был обладателем лицензии и имел право на полноценный суппорт.
Вы хотите уязвимости в полном понимании этого слова? ОК, будет Вам и это :)
Вы хотите уязвимости в полном понимании этого слова? ОК, будет Вам и это :)
Если уж речь зашла о касперском, то почему бы и не рассказать о некоторых его уязвимостях.
В эмуляторе существует масса уязвимостей для его обхода, одну из них я публиковал недавно здесь. Она заключалась в баге при проверке апи. Очень смешным оказывается то, что эмулятор таже не может нормально обрабатывать виндовые месаджи, что дает нам плюс один к дыркам. А вот еще забавная фишка на тему многострадального эмула — простым циклом можно запаузить выполнение малвара секунд на 10-15, что ему никак не повредит, но вот эмул просто сделает терминейт по таймауту. О целостности системных структур в нем я вообще молчу. С хипсом тоже много веселого. Достаточно посмотреть в сторону rpc хендлера — его вообще нет, что дает полный произвол хотябы в том же AddPrintProvidor(), не требующем привилегий. Что уж тут говорить о приватных дырках, если публичные до сих пор не пофиксены.
В эмуляторе существует масса уязвимостей для его обхода, одну из них я публиковал недавно здесь. Она заключалась в баге при проверке апи. Очень смешным оказывается то, что эмулятор таже не может нормально обрабатывать виндовые месаджи, что дает нам плюс один к дыркам. А вот еще забавная фишка на тему многострадального эмула — простым циклом можно запаузить выполнение малвара секунд на 10-15, что ему никак не повредит, но вот эмул просто сделает терминейт по таймауту. О целостности системных структур в нем я вообще молчу. С хипсом тоже много веселого. Достаточно посмотреть в сторону rpc хендлера — его вообще нет, что дает полный произвол хотябы в том же AddPrintProvidor(), не требующем привилегий. Что уж тут говорить о приватных дырках, если публичные до сих пор не пофиксены.
Молодой человек, лично я — не хочу, мне не очень интересно наличие или отсутствие уязвимостей в антивирусе Касперского — я им не пользуюсь.
Я только хочу чтобы вы поняли отличие между багом функционала и уязвимостью продукта. И оперировали фактами а не декларациями максимализма — наказать, всех порвать, вон с рынка и все такое. Это к сожалению типичная обывательская позиция человека который сам не участвовал в коммерческой разработке.
Намекающую фотографию уже привели чуть ниже.
BTW: от плюса вам за Responsible Disclosure не отказываюсь, только слова «я им писал, давно и искать влом» — это не подтверждение. Сказать можно многое, гораздо реже это сопровождается какой-либо конструктивной деятельностью.
Я только хочу чтобы вы поняли отличие между багом функционала и уязвимостью продукта. И оперировали фактами а не декларациями максимализма — наказать, всех порвать, вон с рынка и все такое. Это к сожалению типичная обывательская позиция человека который сам не участвовал в коммерческой разработке.
Намекающую фотографию уже привели чуть ниже.
BTW: от плюса вам за Responsible Disclosure не отказываюсь, только слова «я им писал, давно и искать влом» — это не подтверждение. Сказать можно многое, гораздо реже это сопровождается какой-либо конструктивной деятельностью.
> вы в белой или в черной шляпе-то?
Гэндальф он как известно серый…
Гэндальф он как известно серый…
Так что давайте сначала определимся — вы в белой или в черной шляпе-то?Судя по топику и комментам автора, он в такой шляпе:
> Не знаю почему вы хотите давать всего 3 дня
Как я понял, 3 дня предлагают давать не на полное устранение бага, а на реакцию на обращение (т.е. на проверку его воспроизводимости и на ответ заявителю).
А уж в своём ответе они могут пообещать в кратчайшие сроки решить проблему и, если баг критичный, попросить пару недель не публиковать о нём информацию.
В этом случае можно идти на встречу и не публиковать первое время.
Как я понял, 3 дня предлагают давать не на полное устранение бага, а на реакцию на обращение (т.е. на проверку его воспроизводимости и на ответ заявителю).
А уж в своём ответе они могут пообещать в кратчайшие сроки решить проблему и, если баг критичный, попросить пару недель не публиковать о нём информацию.
В этом случае можно идти на встречу и не публиковать первое время.
за 3 дня могут не успеть и среагировать — все-таки в крупных компаниях бюрократия поболее чем в мелких, а в мелких часто бывает «некогда»… В общем я считаю что 3 дня это все равно радикализм. Хотя бы неделю и спустя этот период — поинтересоваться — как дела, вы типа видели я там прислал неделю назад?
Я просто хорошо представляю себе ситуацию когда от «первого заявления» клиента до реального действия программиста может проходить много времени — тупо некогда, да и не всегда так просто воспроизвести ситуацию. Ибо часто претензии присылаются в виде скриншота в ворде и комментария «у меня не работает». Правильно описать воспроизводимый баг или уязвимость — тоже надо уметь.
удивительно что не кто ещё не привёл: http://www.wiretrip.net/rfp/policy.html, обычно публикуется сведения уязвимости по истечению 14 календарных дней после первого ответа разработчика, если он не сообщил дату когда выйдет патч.
А нужно ли выкладывать, Считаю что ДА, что будет стимуляцией для улучшения как самого функционала программы, так и безопасности.
А нужно ли выкладывать, Считаю что ДА, что будет стимуляцией для улучшения как самого функционала программы, так и безопасности.
после чего через три дня опубликовать это для всех.Не согласен со сроками. Нужно уведомить и получить ответ от производителя о сроках. Если нет ответа, то хотя бы месяц давать.
Поясните, пожалуйста, аргументированно: почему месяц?
может чтобы 0-day длился этот месяц?
а почему 3 дня?
Если компания большая и продукт «крупный», то для того, чтобы придумать правильное решение для устранения бага уйдет, скажем, 1 день. А для того, чтобы закоммитить его, оттестировать всесторонне (а вдруг это изменение повлияет на какой-нибудь из 100500 других частей программного комплекса?) понадобится бюрократической машине пару недель. Итоговая цель то —сделать мир лучшене навредить юзерам, выдав скрипткиддисам уязвимость, при этом таки добиться устранения уязвимости, не молчать. Вот и нужен компромисс. Три дня — это не компромисс.
Если компания большая и продукт «крупный», то для того, чтобы придумать правильное решение для устранения бага уйдет, скажем, 1 день. А для того, чтобы закоммитить его, оттестировать всесторонне (а вдруг это изменение повлияет на какой-нибудь из 100500 других частей программного комплекса?) понадобится бюрократической машине пару недель. Итоговая цель то —
Найми больше бета-тестеров, заплати им более достойную зарплату. За счёт урезания зарплаты тех программистов, что сделали бажный код.
А не можешь — есть те, кто смогут. Подчёркиваю: это — рынок.
А не можешь — есть те, кто смогут. Подчёркиваю: это — рынок.
батенька, вы — максималист.
Урезать зарплату программистам? Такая компания вылетит в трубу.
Нанимать студентов с зарплатой специалистов? Такая компания обанкротится.
А это тут при чем? Нанимать надо специалистов на одни должности с одной зарплатой, а студентов на другие должности, с другой зарплатой.
Как при чём? Если товарищ выполняет техзадание, стабильно допуская ряд ошибок — он достоин зарплаты специалиста?
Я не говорю о единичных случаях но если, к примеру, товарищ стабильно портачит прорисовку меню — закроет одну багу, сделает новую — ему что, премию надо давать?
Я не говорю о единичных случаях но если, к примеру, товарищ стабильно портачит прорисовку меню — закроет одну багу, сделает новую — ему что, премию надо давать?
Если вы взяли на работу человека, который стабильно допускает ошибки, то урезать зарплату нужно вам.
А если серьезно, то для уменьшения количества багов можно прибегать не только к экономическим методам — Code Review перед занесением в репозиторий даст больше, чем штрафы.
А если серьезно, то для уменьшения количества багов можно прибегать не только к экономическим методам — Code Review перед занесением в репозиторий даст больше, чем штрафы.
Падение доходов моего бизнеса — достаточное наказание, чем урезание самому себе собственной зарплаты :)
Я рад, что мы пришли к пониманию и я согласен, что экономический вариант — не единственный. Я привёл его для примера и естественно наём бета-тестеров в счёт программеров — не универсальный и не единственный выход.
Я рад, что мы пришли к пониманию и я согласен, что экономический вариант — не единственный. Я привёл его для примера и естественно наём бета-тестеров в счёт программеров — не универсальный и не единственный выход.
Я хотел подчеркнуть, что это не то что «не универсальный и не единственный выход» — а напротив, ошибочное решение. Человек пишет больше багов? Пусть нач. отдела внимательнее делает Code Review, пусть CR делает несколько человек, и т.д. Добавьте TDD.
Переведите в другой отдел, может у человека душа к менюшкам не лежит. И т.д.
Переведите в другой отдел, может у человека душа к менюшкам не лежит. И т.д.
Вы на работу принимаете? Мне Ваша политика в отношении персонала уже нравится :)
Про такую политику в отношении персонала я прочитал в блоге одного разработчика из MS. Соотнеся эту политику с изменением стабильности работы Windows с 95 версии по XP (не было Висты, когда я это читал), несколько проникся ею ). Могу поделиться ссылкой.
Не в этом случайно? ;)
стоит только начать срезать программисту зарплату за баги, как слаженную работу можно считиать оконченной.
обычно программиста берут на некоторую должность и повышают зарплату за аналичие успехов.
но я нигде, даже в самых неадекватных фирмах не видел срезания зарплаты за баги.
потому что это — пи**ец рабооте.
обычно программиста берут на некоторую должность и повышают зарплату за аналичие успехов.
но я нигде, даже в самых неадекватных фирмах не видел срезания зарплаты за баги.
потому что это — пи**ец рабооте.
Девять женщин не родят одного ребёнка за месяц.
эм… читали книгу «мифический человекомесяц»?
в целом, там о том, что ели мы увеличиваем количествоо разработчиков — то время разработки не будет уменьшаться пропорционально.
то же самое и с тестированием.
если у 5 тестировщиков на что-то уходит неделя, то у 35 на это оне уйдет 1 день.
потому что тестирование состоит из многих этапов. анализ, создание плана тестирования, создание среды, тестирование. написание новых автотестов итд.
«партизанское тестирование» — это не круто.
плюс к этому, надо себе четко понимать, что тестирование — это не «удостовериться, что всё ок», а обычно всё же «найти проблемы». тестировщики они обычно баги находят. и эти баги надо фиксить.
я длительное время работал тестировщиком — и как меня бесило в одной фирме, когда руководитель проекта планировал «вот мы три месяца разрабатываем, а потом тестируем за недельку — и релиз». фикс багов как-то не вмещался :)
в целом, там о том, что ели мы увеличиваем количествоо разработчиков — то время разработки не будет уменьшаться пропорционально.
то же самое и с тестированием.
если у 5 тестировщиков на что-то уходит неделя, то у 35 на это оне уйдет 1 день.
потому что тестирование состоит из многих этапов. анализ, создание плана тестирования, создание среды, тестирование. написание новых автотестов итд.
«партизанское тестирование» — это не круто.
плюс к этому, надо себе четко понимать, что тестирование — это не «удостовериться, что всё ок», а обычно всё же «найти проблемы». тестировщики они обычно баги находят. и эти баги надо фиксить.
я длительное время работал тестировщиком — и как меня бесило в одной фирме, когда руководитель проекта планировал «вот мы три месяца разрабатываем, а потом тестируем за недельку — и релиз». фикс багов как-то не вмещался :)
Есть ещё вариант: открытое тестирование бета-продукта. Наиболее ярым тестировщикам — какие-то символические премии. При популярно продукта желающих потестировать будет достаточно, а «премии» в сумму будут ниже затрат на постоянный штат.
Единственная проблема — грамотное отслеживание багтрека и координация. Тут Вы совершенно правы.
Единственная проблема — грамотное отслеживание багтрека и координация. Тут Вы совершенно правы.
в один-три дня открытое тестирование ну никак не уложится.
тем более, что при исправлении бага требуется регрессионное тестирование.
которое чаще всего автоматическое.
для которого, скорее всего, понадобится написать какое-то количество новых тестов.
тем более, что при исправлении бага требуется регрессионное тестирование.
которое чаще всего автоматическое.
для которого, скорее всего, понадобится написать какое-то количество новых тестов.
У больших корпораций большие обязательства blogs.msdn.com/b/ericlippert/archive/2003/10/28/how-many-microsoft-employees-does-it-take-to-change-a-lightbulb.aspx
ну да, а пользователи продукта целый месяц будут использовать заведомо уязвимую версию. 3 дня достаточно чтобы сделать workaround, потом еще пару дней чтобы написать фикс. естественно это касается коммерческих продуктов.
А сложившаяся практика такова, что в зависимости от целей искавшего, найденный баг
или «обналичивают», если он найден в среде «коммерческого» андеграунда, а потом, часто далеко не сразу, публикуют так или иначе
или, в случае некоммерческого интереса, отсылают разработчику и публикуют в сети с той же целью зачем публикуют научные статьи ;)
По крайней мере в большинстве так, IMHO
или «обналичивают», если он найден в среде «коммерческого» андеграунда, а потом, часто далеко не сразу, публикуют так или иначе
или, в случае некоммерческого интереса, отсылают разработчику и публикуют в сети с той же целью зачем публикуют научные статьи ;)
По крайней мере в большинстве так, IMHO
Правильное делоустройство этой дилеммы достигается тогда, когда за обнаружение уязвимости платятся реальные деньги — так что тяготы ожидания для хакера, нашедшего уязвимость и сообщившего разработчику, снимаются наградою от разработчика.
ну-ну,
Многим заикнувшимся об оплате за найденную уязвимость, от разрабочиков прилетали только обвинения в вымогательстве. И хорошо когда лишь на словах…
С другой стороны, если у вас есть хоть какойто самописный сайт, или система, вам наверняка приходили предложения за $$$ показать в этой системе дыры…
Многим заикнувшимся об оплате за найденную уязвимость, от разрабочиков прилетали только обвинения в вымогательстве. И хорошо когда лишь на словах…
С другой стороны, если у вас есть хоть какойто самописный сайт, или система, вам наверняка приходили предложения за $$$ показать в этой системе дыры…
Публикация багов — это конечно хорошо. Но я лично вижу одно но — это то, что вопрос в этой проблеме даже не в том, как разработчик быстро выпустит фикс проблемы, а то, как быстро этот фикс дойдет до конечного потребителя. Взять ту же винду, как бы быстро MS не выпускали патчи, останутся тонны пользователей с нелицензионной виндой и отрубленным windows update. И в результате публикации бага мы почти гарантированно подписываем эту тонну пользователей на мучительную смерть от эксплоита.
А без волков не было бы таких быстроногих и грациозных оленей в лесу…
Ну это не проблема, если мы будем ориентироваться и на пиратов — мы на месте будем топтаться. Если ставишь пиратский софт — принимай на себя меру ответственности, отдавай себе отчет в том, что и троянчик в кряке быть может, и апдейтов ты быстрых не получишь. Хочешь пользоваться софтом нормально — плати.
Я говорю не только про пиратов, а про ту прослойку пользователей, которые сами обновлять ничего не будут (боже упаси). Это может быть и Ваша мама в другом городе и Ваша девушка на Сейшелах. Они будут мирно и тихо ждать вашего приезда к ним (месяца через три) становясь попутно разсадником вирей… и вы приехав к ним конечно же обновите всё ПО до последнего (это по GPRS-каналуто) и будут все счастливы.
Ну если рассматривать совсем экстремальные ситуации, когда отключен автоапдейт, не установлен антивирь, а интернет только через дерьмовенький радиоканал — то да, всегда есть группа риска, но этих людей гораздо меньше, чем тех, кто сидит на нормальном канале и качает апдейты автоматом и вовремя (кстати скорее именно эти машину будут подвергнуты атаке, а не кто-то на GPRS соединении), поэтому уж лучше быстрое исправления багов для большинства, чем медленной но с равной угрозой для всех.
И… не ориентировать на пиратов — это тоже отчасти проблема. Ибо часть этих пользователей формирует общее мнение о нашем продукте. И фразы «а у меня в винде столько вирей» так или иначе будет влиять на общие настроения в том числе и у легальных пользователей.
Может немного неправильное сравнение — но ваше сообщение напоминает аналогию с ММОРПГ, типа того же WoW. Куча людей играет и радуется, но есть кучка людей, поигравших на пиратке, кричащая какое же WoW говно. Наносит ли это урон имиджу WoW? Скорее да. Может ли на это повлиять Blizzard? Вряд ли. Тут то же самое, от того что кто-то украл у МС винду и поставил себе на машину не должно заставлять МС пытаться влиять на ситуацию с обновлением пиратских копий.
Конечно, уведомлять производителя софта нужно, но если в дополнение к этому есть публикация в открытом источнике, как показывает опыт, уязвимость закрывается в разы быстрее. А утверждать что публикация зло, а нужно ждать когда же бедный разработчик освободится от пририсования очередной фигулечки и приступит наконец к прикрытию дырки — ИМХО крайне глупо и выставляет производителя софта далеко не в лучшем свете. Да, конечно, их жизнь была бы лечге без таких публикаций, но в конце-концов, баги-то тоже они наделали!
Вполне нормально, но только есть момент. На устранение бага может потребоваться не 3 дня, а и 3 недели. Эксплойт написать это одно, а закрыть дыру, не наделав при этом десяток новых, — это другое. Ошибки могут быть допущены на разных уровнях разработки, а потому и время на исправление может быть самым разным.
Если и отправлять уведомление о баге, то с обратным адресом для связи. В этом случае разработчики за эти 3 дня должны адекватно оценить сроки устранения бага и сообщить об этих сроках нашедшему дыру.
А руководствоваться принципом «да мне похер, у них есть аж целых 3 дня, чтобы залатать дыру в системной библиотеке, не ими и написанной, а после этого еще и накатить обновления у всех своих клиентов» считаю неправильным. Это просто не по-людски как-то.
Вот если разрабы молчат этих 3 дня, тогда да, нормально так поступать.
Если и отправлять уведомление о баге, то с обратным адресом для связи. В этом случае разработчики за эти 3 дня должны адекватно оценить сроки устранения бага и сообщить об этих сроках нашедшему дыру.
А руководствоваться принципом «да мне похер, у них есть аж целых 3 дня, чтобы залатать дыру в системной библиотеке, не ими и написанной, а после этого еще и накатить обновления у всех своих клиентов» считаю неправильным. Это просто не по-людски как-то.
Вот если разрабы молчат этих 3 дня, тогда да, нормально так поступать.
А я согласен с этим «представителем». Разработчики то может и закроют дырку за пару дней, но пользователи точно не успеют обновиться. Отсюда — дырявый софт у пользователей + все знают как его сломать = масса недовольных пользователей и горы критики в адрес разработчиков. Пользователи перестанут покупать этот софт и компания понесет убытки, хотя и исправила баг быстро и качественно.
Если Вы наберёте format c: и со всем согласитесь — это не проблема Windows, а Ваша. Если Вы отключили обновления — то это не проблема разработчика, а Ваша.
Если на каждом углу кричать, что «я отключил обновления, а почему ко мне не приехал Билл Гейтс и лично не установил критикал фиксы» — то не думаю, что Вас воспримут всерьёз и продажи у кого-то упадут.
Если на каждом углу кричать, что «я отключил обновления, а почему ко мне не приехал Билл Гейтс и лично не установил критикал фиксы» — то не думаю, что Вас воспримут всерьёз и продажи у кого-то упадут.
Пользователя не волнует чья это проблема, его не беспокоит, что он что-то там где-то не обновил. «Программа не работает — разработчик мудак» — вот обычное мнение обычного пользователя. Когда у вас будет своя компания и ваш софт будут активно покупать, я думаю, вы измените своё мнение.
Увы компании у меня крупной нет, но с проблемой я сталкивался с двух сторон. «Разработчик мудак» — да, он именно это слово и не раз, если во время какой-то долгосрочной и сложной операции у меня винда решила обновиться, а я отошел и она перезагрузила компьютер(все наверное сталкивались?)
Да он такой — если чтобы обновиться мне нужно каждый день лазить к нему на сайт в поисках появившихся исправлений продукта(я согласен, что это можно вытерпеть когда продукт бесплатный, но когда он хочет денег и обычно немало???)
Да он снова такой — когда при установке апдейта слетают профили или то что работало работать перестает.
Так что если пользователь так считает может обоснованно?? Может нужно все-таки думать о пользователях готовясь к обновлениям продукта?
Да он такой — если чтобы обновиться мне нужно каждый день лазить к нему на сайт в поисках появившихся исправлений продукта(я согласен, что это можно вытерпеть когда продукт бесплатный, но когда он хочет денег и обычно немало???)
Да он снова такой — когда при установке апдейта слетают профили или то что работало работать перестает.
Так что если пользователь так считает может обоснованно?? Может нужно все-таки думать о пользователях готовясь к обновлениям продукта?
Все зависит от того, что и кому вы хотите сделать.
Если вы хотите сделать хорошо пользователям — отправьте письмо разработчикам, если не будет ответа (скажем, в течение месяца), раскройте некоторые детали уязвимости публике. Еще через месяц — опубликуйте полный отчет об уязвимости. Еще через месяц — добавьте к этому рабочий эксплойт.
Если вы хотите сделать хорошо скрипт-киддиз — опубликуйте рабочий эксплойт сразу же. Ну или через 3 дня — ведь это однозначно малый срок для фикса бага и его распространения по клиентам.
Хотите сделать хорошо своему кошельку и неизвестным взломщикам? Продайте эксплойт на «черном рынке».
Хотите сделать хорошо только своему кошельку? Продайте свои услуги на «черном рынке».
Хотите потешить свое эго? Публикуйте сразу же, да еще и напишите на хабр гневное письмо — «они не реагируют на мои письма!»
Если вы хотите сделать хорошо пользователям — отправьте письмо разработчикам, если не будет ответа (скажем, в течение месяца), раскройте некоторые детали уязвимости публике. Еще через месяц — опубликуйте полный отчет об уязвимости. Еще через месяц — добавьте к этому рабочий эксплойт.
Если вы хотите сделать хорошо скрипт-киддиз — опубликуйте рабочий эксплойт сразу же. Ну или через 3 дня — ведь это однозначно малый срок для фикса бага и его распространения по клиентам.
Хотите сделать хорошо своему кошельку и неизвестным взломщикам? Продайте эксплойт на «черном рынке».
Хотите сделать хорошо только своему кошельку? Продайте свои услуги на «черном рынке».
Хотите потешить свое эго? Публикуйте сразу же, да еще и напишите на хабр гневное письмо — «они не реагируют на мои письма!»
Вы абсолютно правы, и специально для того, чтобы не было двусмыслия я поправил пост. Речь идёт от трёхдневном молчании. При активной переписке со стороны разраба — все мы люди и всё понимаем. Если же ответа нет или он из разряда «а мы давно знаем, это некритично» — тогда руки развязаны.
К Вашему примеру тоже замечание: если разработчик поддерживает код А (как я понимаю — предыдущая версия программы) и не заставляет в одностороннем порядке переходить на Б — то он обязан выполнить и обновление А, и обновление Б. А с точки зрения «сырости» кода — отложить релиз Б для дополнительного тестирования.
К Вашему примеру тоже замечание: если разработчик поддерживает код А (как я понимаю — предыдущая версия программы) и не заставляет в одностороннем порядке переходить на Б — то он обязан выполнить и обновление А, и обновление Б. А с точки зрения «сырости» кода — отложить релиз Б для дополнительного тестирования.
Красивый тараканчик, не убивайте его пожалуйста.
№1 —
Увидели експлоит — написали в саппорт.
НЕт ответа?
делаем паблик.
Сроки? Если в компании тех. служба проверяет мыло раз в неделю — это сугубо ее проблемы.
Электронная почта отличает от обычной возможностью практически мгновенно увидеть письмо.
№ 2 —
Увидели експлоит — написали в саппорт.
Есть ответ?
3 дня работы — должен быть патч. Не геройствуйте — если Вы до этого додумались — значит еще кто-то тоже. И он уже юзает експлоит.
Если саппорт будет телится месяц — да ну нах такой продукт на рынке. Они же его продали за бабло, верно? Пусть работают теперь.
№3 — Нашли багу?
Сделали и патч и експлоит.
Если саппорт телится — все в паблик.
И жаба давить не будет, и совесть чиста.
Саппорт выпустил патч, тупо переписав Ваш? В суд — к ядреной фени.
Или продукт должен продаваться за деньги и иметь соответственный саппорт или в опенсорс.
Увидели експлоит — написали в саппорт.
НЕт ответа?
делаем паблик.
Сроки? Если в компании тех. служба проверяет мыло раз в неделю — это сугубо ее проблемы.
Электронная почта отличает от обычной возможностью практически мгновенно увидеть письмо.
№ 2 —
Увидели експлоит — написали в саппорт.
Есть ответ?
3 дня работы — должен быть патч. Не геройствуйте — если Вы до этого додумались — значит еще кто-то тоже. И он уже юзает експлоит.
Если саппорт будет телится месяц — да ну нах такой продукт на рынке. Они же его продали за бабло, верно? Пусть работают теперь.
№3 — Нашли багу?
Сделали и патч и експлоит.
Если саппорт телится — все в паблик.
И жаба давить не будет, и совесть чиста.
Саппорт выпустил патч, тупо переписав Ваш? В суд — к ядреной фени.
Или продукт должен продаваться за деньги и иметь соответственный саппорт или в опенсорс.
Да вот как-то знаете, пока не сталкивался с таким чтобы после нахождения какой-то очень критической уязвимости в ядре линукс сознательные граждане не обратили бы на это внимаения да не пропатчили ядро. Если не пропатчили, сами себе буратины… а уж с проприетарщиной что хотите то и делайте, аналогично сами себе буратины… Имхо о проблемах надо знать по скольку по стольку, внепатча можно придумать workarround, ну в особо страшных случаях оценить риск и убытки и выключить компьютер… Насчет эксплойтов ничего сказать не могу, но выставление их на публичное обосзрение это скорее позерство чем польза…
Ох уж эти спасатели всего и вся. Подростковый максимализм да и только.
Вы о пользователях, не умеющих и не хотящих обновлять ПО думали? А о админах-дуралеях не позволяющих слезать с устаревших программ? А о тех кому не известно или вообще наплевать ибо и без того дел невпроворот?
Вы такой замечательный выпустите описание критического бага, вирусов напишут, а в итоге проиграет не производитель ПО, а обычные юзеры. Не верите — вспомните микрософт.
Пускай ботнеты растут, зато ваше собственное маленькое ЧСВ подрастёт ещё на немного.
Вы о пользователях, не умеющих и не хотящих обновлять ПО думали? А о админах-дуралеях не позволяющих слезать с устаревших программ? А о тех кому не известно или вообще наплевать ибо и без того дел невпроворот?
Вы такой замечательный выпустите описание критического бага, вирусов напишут, а в итоге проиграет не производитель ПО, а обычные юзеры. Не верите — вспомните микрософт.
Пускай ботнеты растут, зато ваше собственное маленькое ЧСВ подрастёт ещё на немного.
Чем вам решение от HP 2-х месячной давности не угодило?
Может добавить к топику опрос?
Лично я придерживаюсь мнения автора.
Лично я придерживаюсь мнения автора.
В корне не согласен с автором-идеалистом. Автор думает, что сможет повлиять на производителя, а на самом деле он лишь навредит добросовестным пользователям.
я так думаю что публиковать однозначно и сразу. свободу распространения информации никто не отменял
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикация найденных уязвимостей: за и против