forum.opennet.ru

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Оглавление

Google предлагает переосмыслить подход к раскрытию информаци..., opennews (??), 23-Июл-10, (0) [смотреть все]

К сожалению работает только full disclosure, посмотрите последние выпуски PHP и , Аноним (-), 09:01 , 23-Июл-10, (1) +5 //

Как вы можете знать, работают ли другие способы, если вы их не видите В том то и, ВДНХ (?), 09:59 , 23-Июл-10, (7) //

s PHP руками gВ руках мастера и палочки - оружие Обезьяна же на танке безопасна, klalafuda (?), 10:16 , 23-Июл-10, (9) –1 //

Да, если выбора не оказалось в конкретный момент Однако, если выбор есть, то хор, ВДНХ (?), 10:29 , 23-Июл-10, (12) +1

Нет, Вы неправильно меня поняли Я не согласен с Вами по поводу низкого качеств, klalafuda (?), 10:44 , 23-Июл-10, (14) –7

То, что вы ставите в одну линию PHP, Perl, Python и Ruby по качеству архитектуры, ВДНХ (?), 11:00 , 23-Июл-10, (19) +4

Да понятно, что PHP не без недостатков, но всё же это далеко не бейсик Писать на, Crazy Alex (??), 16:05 , 23-Июл-10, (54)

Ну если вы можете сравнить только с бейсиком - то конечно Писать и на бумаге хор, ВДНХ (?), 16:36 , 23-Июл-10, (56) +3

не верно вы и все-все окружающие могут ездить на машинах всегда по правилам, но, Аноним (-), 12:22 , 23-Июл-10, (29) +3
Как полагаете -- руки, которыми такое пишется, как можно назвать PS такое , Michael Shigorin (ok), 14:04 , 23-Июл-10, (41)

А как насчет обезьяны с гранатой , User294 (ok), 14:30 , 23-Июл-10, (46)

Ну если рассуждать с научной точки зрения, то вероятность того, что она грамотно, XoRe (ok), 20:43 , 23-Июл-10, (72) –2

Итак, речь шла о факторах, влияющих на количество багов в проектах и мерах их пр, ВДНХ (?), 09:59 , 24-Июл-10, (81)

Почему не вижу Не вижу только до выхода исправленной версии Как только версия, Аноним (-), 10:23 , 23-Июл-10, (10) //

Потому что у вас упрощенный и идеализированный взгляд на мир А кто вам сказал, ч, ВДНХ (?), 10:34 , 23-Июл-10, (13) –1

Есть цивилизованный способ сообщать об ошибках разработчикам, не придавая ошиб, ВДНХ (?), 15:19 , 23-Июл-10, (50)

Это хорошо, если подробно объясняется А вы можете спорить с человеком, не старая, XoRe (ok), 14:28 , 24-Июл-10, (85)

Я вообще-то говорил о зависимости количества багов от качества проектирования А , ВДНХ (?), 15:10 , 24-Июл-10, (88)

А он вообще очень полезное лекарство от раздолбайства ИМХО гугл дело говорит - , User294 (ok), 14:32 , 23-Июл-10, (47) +2

Дело за малым заставить пользователей конкретного продукта в массовом порядке с, klalafuda (?), 09:16 , 23-Июл-10, (2) //

PS Да, и, если уж ставить себе глобальную задачу бороться за мир во всем мире, , klalafuda (?), 09:19 , 23-Июл-10, (3) //

И в чем суть вашего сарказма Вы описали то, что существует, так, какбудто этого, ВДНХ (?), 13:08 , 23-Июл-10, (35) +1 //

Применительно конкретно к браузерам этого нет Достаточно взглянуть на статы use, klalafuda (?), 15:26 , 23-Июл-10, (52) –1

Чего именно _этого_ нет И как один умрем в борьбе за _это_ Вы, собственно что , ВДНХ (?), 15:41 , 23-Июл-10, (53)

Неидеально - это как бы это сказать, это несколько смазано Я бы сказал чуть точ, klalafuda (?), 16:14 , 23-Июл-10, (55) –1

В исходном посте вы говорили так, как будто автообновления вообще не существует , ВДНХ (?), 17:16 , 23-Июл-10, (58)

Повторю свой вопрос у Вас будут какие-то конкретные технические предложения по , klalafuda (?), 17:44 , 23-Июл-10, (59)

Если вы хотите услышать конкретные технические предложения, сформулируйте ваши в, ВДНХ (?), 18:14 , 23-Июл-10, (62)

Желание гугла понятно - иметь неограниченно большое время на исправление уязвимо, koblin (ok), 09:23 , 23-Июл-10, (4) –13 //

Желание создателей и владельцев Гугла - максимально извлекать выгоду, благодаря , ВДНХ (?), 10:05 , 23-Июл-10, (8) +1
Ты статью точно читал дальше первого абзаца , Lain_13 (?), 10:59 , 23-Июл-10, (18) +4

И что в этой демагогии нового, чего мы как бы не знали и не практиковали , filosofem (ok), 09:29 , 23-Июл-10, (5) –2 //

Это рекомендация мировому сообществу от всемирно известной корпорации Этим и ра, Lain_13 (?), 11:25 , 23-Июл-10, (26) +2
Хм, а можно поинтересоваться, что именно _Вы_ как security researcher практикует, Michael Shigorin guest (?), 11:48 , 23-Июл-10, (28) +2 //

Поинтересоваться можно Кто же вам запретит , filosofem (ok), 12:59 , 23-Июл-10, (33) –4 //

Тогда представьте список найденных и отрепорченных Вами уязвимостей, пожалуйста , Michael Shigorin (ok), 14:12 , 23-Июл-10, (42) +2

Может быть еще ключ от квартиры где девки визжат , filosofem (ok), 14:17 , 23-Июл-10, (44) –4

Полагаю, его у Вас тоже нет , Michael Shigorin (ok), 17:21 , 24-Июл-10, (90)

Давать срок три дня и разглашать всю информацию , Аноним (-), 09:40 , 23-Июл-10, (6) +3 //

та не, 2 часа достаточно , splat_pack (ok), 10:44 , 23-Июл-10, (15) +4
Почему именно 3 дня Правда интересно откуда такая цифра появилась , filosofem (ok), 13:07 , 23-Июл-10, (34)

Всегда удивляло скорее даже бесило когда люди нагло и бесстыжи прикрываются за, SaveMeGood (??), 10:58 , 23-Июл-10, (16) +2 //

Открывать информацию о дыре по-принципу полного раскрытия не этично в первую оче, Lain_13 (?), 11:06 , 23-Июл-10, (20) +2

В подходе Полное раскрытие упустили еще одно очень важное достоинство Имея ин, Maris (?), 11:09 , 23-Июл-10, (21) +3 //

В случае простой уязвимости и срок будет на её решение установлен короткий всё , Lain_13 (?), 11:21 , 23-Июл-10, (24)
Пользователю достаточно сообщить, что уязвимость имеется и чем не надо пользо, filosofem (ok), 13:12 , 23-Июл-10, (36)
Не любой, а достаточно квалифицированный и притом заинтересованный в срочнейшем , Michael Shigorin (ok), 14:17 , 23-Июл-10, (43)

60 дней это слишком много, 7 ну максимум А лучше 3, i (??), 11:40 , 23-Июл-10, (27) –1 //

по хорошему, перед раскрытием уязвимости, нужно ждать пока ее исправят разработч, Аноним (-), 12:28 , 23-Июл-10, (30) +2 //

что можно исправлять ДВА месяца не понимаю Ну пару дней ещё пока заплатка по ю, i (??), 12:41 , 23-Июл-10, (31) –1 //

Жирные архитектурные косяки, что же ещё , Lain_13 (?), 12:54 , 23-Июл-10, (32) +3
Неизвестнуюю массам дыру не закроют быстро Ибо зачем, все равно никто не знает , fr0ster (ok), 13:36 , 23-Июл-10, (38)
Просто сиутации разные бывают Разработчик именно этой подсистемы может свалить в, XoRe (ok), 14:24 , 24-Июл-10, (84) +1

1 А что делали тестировщики до этого 2 А то что у пользователь изза этой дыры мо, fr0ster (ok), 15:18 , 24-Июл-10, (89)

Вы доверяете _софту_ PS я -- нет, только людям , Michael Shigorin (ok), 17:22 , 24-Июл-10, (91)
то есть, если уязвимость через два дня откроют, то у юзера меньше возможностей п, Аноним (-), 21:32 , 24-Июл-10, (92)

Кто следит за используемым софтом сможет или самостоятельно костыли прикрутить, , fr0ster (ok), 05:03 , 25-Июл-10, (93)

Ну, блин, мы говорим и про обычных домашних юзеров тоже Они ни за чем ни следят,, XoRe (ok), 17:23 , 26-Июл-10, (100)

Заражение вирусом машин хомячков одного провайдера с образованием ботнета привед, fr0ster (ok), 19:03 , 26-Июл-10, (106)

Тестировали другие _известные_ дырки, очевидно же Каким образом Если инфу о ды, XoRe (ok), 17:22 , 26-Июл-10, (99)

Вы правда думаете, что уязвимость может только кто то один найти 1 Система все р, fr0ster (ok), 18:59 , 26-Июл-10, (104)
Вы правда думаете, что уязвимость может только кто то один найти 1 Система все р, fr0ster (ok), 19:01 , 26-Июл-10, (105)

Допустим, проект крупный, и только полностью пересобирается почти сутки Допусти, nuclight (ok), 00:10 , 26-Июл-10, (94)

Скажите это крупным корпорациям Юзайте программы типа echo, cat, grep, head, ta, XoRe (ok), 17:26 , 26-Июл-10, (101)

Да Даёшь Корпоративный Конвейер http www opennet ru openforum vsluhforumI, Andrey Mitrofanov (?), 18:36 , 26-Июл-10, (102)
Да, считающему себя программистом обычно скучать некогда, если других способов б, ВДНХ (ok), 10:30 , 27-Июл-10, (114)

ну тут так если бы платили за приватные баги и по качественное было бы А так в , Аноним (-), 13:14 , 23-Июл-10, (37)
Неоднократно наблюдал, когда security team в Debian или Red Hat правили уязвимос, uldus (ok), 13:36 , 23-Июл-10, (39) //

В альте, как и в OpenBSD, нередко бывали случаи у нас эта дырка не работает --, Michael Shigorin (ok), 14:19 , 23-Июл-10, (45) +1
Что не помешало RedHat-у внести в репы firefox 3 6 4 лишь совсем недавно До это, klalafuda (?), 16:47 , 23-Июл-10, (57) –1 //

Что именно не помешало Судя по контексту вы отождествляете правку уязвимостей , ВДНХ (?), 17:45 , 23-Июл-10, (60)
В Debian Sid вчера вечером ещё был firefox, пардон, iceweasel 3 5 11 Не все ку, Bod (??), 20:06 , 23-Июл-10, (69)

Предлагаемый гуглом метод попахивает шантажом А кто-нибудь из кретинов именно т, Аноним (-), 17:47 , 23-Июл-10, (61) –1 //

А когда дыру зарепортили но за годы так и не было починено и в итоге все пришло , User294 (ok), 19:19 , 23-Июл-10, (68) +1 //

full disclosure работает в данном случае лучше предложенного, ИМХО По крайней м, Аноним (-), 20:25 , 23-Июл-10, (70) –1

Предлагаю дополнение Если руководитель отказывается реагировать на запрос, или е, XoRe (ok), 20:54 , 23-Июл-10, (74) –1 //

А почему административные грабли какой-то конторки команды должны парить ког, User294 (ok), 14:55 , 24-Июл-10, (87)

Сообщения [Сортировка по времени | RSS]

7. "Google предлагает переосмыслить подход к раскрытию информаци..." +/–

Сообщение от ВДНХ (?), 23-Июл-10, 09:59

> К сожалению работает только full disclosure, посмотрите последние выпуски PHP и Firefox, в PHP поправили дыры о которых приватно сообщили в мае, а в Firefox - в марте. Одновременно в Firefox почти мгновенно поправили дыру о которой стало известно публично.
Как вы можете знать, работают ли другие способы, если вы их не видите?
В том то и суть, чтобы было больше дела, и меньше зависеть от от пустых крикунов.
Своевремменность нахождения и исправления ошибок зависит в первую очередь от качества архитектуры проекта. Если архитектура корявая - потом кричи, не кричи об ошибках - их будет море.
Как это можно наблюдать с PHP.

Ответить | Правка | Наверх | Cообщить модератору

9. "Google предлагает переосмыслить подход к раскрытию информаци..." –1 +/–

Сообщение от klalafuda (?), 23-Июл-10, 10:16

s/PHP/руками/g
В руках мастера и палочки - оружие. Обезьяна же на танке безопасна.

Ответить | Правка | Наверх | Cообщить модератору

12. "Google предлагает переосмыслить подход к раскрытию информаци..." +1 +/–

Сообщение от ВДНХ (?), 23-Июл-10, 10:29

>s/PHP/руками/g
>
>В руках мастера и палочки - оружие. Обезьяна же на танке безопасна.
Да, если выбора не оказалось в конкретный момент.
Однако, если выбор есть, то хороший мастер выбирает хороший инструмент.
Хотя, я так понял, вы согласны со мной относительно низкого качества PHP.
А сравнивать палочки и танк по качеству - нелогично. Вы явно путаете качество с размером и назначением.
Могут быть качественные палочки и некачественный танк.

Ответить | Правка | Наверх | Cообщить модератору

14. "Google предлагает переосмыслить подход к раскрытию информаци..." –7 +/–

Сообщение от klalafuda (?), 23-Июл-10, 10:44

Нет, Вы неправильно меня поняли. Я не согласен с Вами по поводу 'низкого качества PHP'. Это точно такой же инструмент, как и все остальные. Perl, Python, Ruby, you name. Ни чем от них не отличающийся. По крайней мере с точки зрения 'качества'.
Поясню проще: с умом можно разрабатывать качественные продукты на любом из них. Кривыми же руками можно испортить абсолютно все, что угодно. И абстрактное 'качество' приведенного в качестве примера PHP тут совершенно не причем. Не стоит списывать дремучую некомпетентность отдельных конечных пользователей на проблемы инструмента.

Ответить | Правка | Наверх | Cообщить модератору

19. "Google предлагает переосмыслить подход к раскрытию информаци..." +4 +/–

Сообщение от ВДНХ (?), 23-Июл-10, 11:00

>Нет, Вы неправильно меня поняли. Я не согласен с Вами по поводу 'низкого качества PHP'. Это точно такой же инструмент, как и все остальные. Perl, Python, Ruby, you name. Ни чем от них не отличающийся. По крайней мере с точки зрения 'качества'.
То, что вы ставите в одну линию PHP, Perl, Python и Ruby по качеству архитектуры, может говорить только о том, что вы плохо представляете себе архитектуру ПО и процессы проектирования.
>Поясню проще: с умом можно разрабатывать качественные продукты на любом из них.
Разрабатывать-то можно, но только не с умом. Продукт может и будет одинакового качества, но себестоимость его производства с помощью инструментов разного качества будет тоже разной. Таких простых вещей не знаете. А еще говорите о компетентности.
>Кривыми же руками можно испортить абсолютно все, что угодно. И абстрактное 'качество' приведенного в качестве примера PHP тут совершенно не причем. Не стоит списывать дремучую некомпетентность отдельных конечных пользователей на проблемы инструмента.
Поздно метаться. Вы сравнивали до этого по качеству танк и палочки.
А ваши поздние оправдания по поводу плохого качества ваших мыслей - сродни тем самым выкрикам о больших количествах найденных и исправленных ошибках, когда качество проектирования было плохим изначально.

Ответить | Правка | Наверх | Cообщить модератору

54. "Google предлагает переосмыслить подход к раскрытию информаци..." +/–

Сообщение от Crazy Alex (??), 23-Июл-10, 16:05

Да понятно, что PHP не без недостатков, но всё же это далеко не бейсик.
Писать на нём хорошо можно, он этому не мешает особо. Не навязывает - это да, но не мешает.
Если, конечно, вы не PHP3 имеете в виду, с register_globals, magic quotes, без ООП и пространств имён.

Ответить | Правка | Наверх | Cообщить модератору

56. "Google предлагает переосмыслить подход к раскрытию информаци..." +3 +/–

Сообщение от ВДНХ (?), 23-Июл-10, 16:36

>Да понятно, что PHP не без недостатков, но всё же это далеко не бейсик.
Ну если вы можете сравнить только с бейсиком - то конечно.
>Писать на нём хорошо можно, он этому не мешает особо.
Писать и на бумаге хорошо можно, она тоже этому не мешает особо.
>Не навязывает - это да, но не мешает.
Этим интересным противопоставлением вы как бы пытаетесь нам сказать, что вам даже тех навязываний, которые есть в PHP не достаточно, но зато вас утешает, что он вам "не мешает особо".
Вообще очень даже много чего навязывает, как многие более примитивнные языки.
Хотя примитивные языки и должны навязывать - стиль, методы решения и др. - в этом их назначение, своеобразная "защита от дурака".
Но ведь речь шла именно о качестве реализации, а это совсем другое. Потому что будучи рожденным, как узко-специализированное средство для веб-разработок, PHP пытается изображать из себя язык общего назначения. А в итоге - "не пава, не ворона". И куча хаотичных заплат во внутренней архитектуре. Плюс еще плохое начальное проектирование даже как узко-специализированного средства. И комьюнити такое же.
Интересно, на каких тогда языках вам "плохо писать", и какие языки вам "танцевать^W писать мешают"?
>Если, конечно, вы не PHP3 имеете в виду, с register_globals, magic quotes, без ООП и пространств имён.
Понятно одно. Вы тоже один из тех, кто плохо представляет себе, что такое архитектура ПО и качество проектирования.
И руководствуетесь преимущественно такими туманными критериями, как "на нем хорошо писать", типа "хорошо сидим".

Ответить | Правка | Наверх | Cообщить модератору

29. "Google предлагает переосмыслить подход к раскрытию информаци..." +3 +/–

Сообщение от Аноним (-), 23-Июл-10, 12:22

>Поясню проще: с умом можно разрабатывать качественные продукты на любом из них. >Кривыми же руками можно испортить абсолютно все, что угодно. И абстрактное
>'качество' приведенного в качестве примера PHP тут совершенно не причем. Не стоит
>списывать дремучую некомпетентность отдельных конечных пользователей на проблемы >инструмента.
не верно. вы и все-все окружающие могут ездить на машинах всегда по правилам, но если вдруг у вашей машины откажут тормоза, то совершенно не очевидно, что вы не соберете впереди едущего.

Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

41. "Google предлагает переосмыслить подход к раскрытию информаци..." +/–

Сообщение от Michael Shigorin (ok), 23-Июл-10, 14:04

>PHP [...] Perl, Python, Ruby, you name. Ни чем от них не отличающийся.
>По крайней мере с точки зрения 'качества'.
Как полагаете -- руки, которыми такое пишется, как можно назвать?.. :(
PS: такое ощущение, что выгорели и устали от проблем "здеся". Не переживайте, тоже порой бывает, но в итоге когда понимаешь, что диагностируемость всё-таки милее -- всё возвращается на круги своя :)

Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

46. "Google предлагает переосмыслить подход к раскрытию информаци..." +/–

Сообщение от User294 (ok), 23-Июл-10, 14:30

>Обезьяна же на танке безопасна.
А как насчет обезьяны с гранатой? :)

Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

72. "Google предлагает переосмыслить подход к раскрытию информаци..." –2 +/–

Сообщение от XoRe (ok), 23-Июл-10, 20:43

>>Обезьяна же на танке безопасна.
>
>А как насчет обезьяны с гранатой? :)
Ну если рассуждать с научной точки зрения, то вероятность того, что она грамотно оторвет чеку, после этого бросит в вас (и умудрится не подорваться сама) - вероятность маленькая)
Хотя смотря какая обезъяна.
Если на вас несется разъяренная горилла, то там пофиг на гранату)
А с кодингом - 99% ошибок идут изза кривизны рук, и 1% - изза ошибок самого языка.
Я бы даже сказал, что соотношение 99,99% и 0,01% =)
Фишка ещё в том, что когда знаешь, что вон в том модуле, или вон в том операторе часто находят ошибки, можно написать код с оглядкой на это.
Т.е. поставить там побольше проверок данных, побольше проверок на error=1 и т.д.
Т.е. руками уменьшить даже вероятность глюка изза ошибки языка.
Обычно наоборот - это язык уменьшает вероятность глюка изза кривых рук)

Ответить | Правка | Наверх | Cообщить модератору

81. "Google предлагает переосмыслить подход к раскрытию информаци..." +/–

Сообщение от ВДНХ (?), 24-Июл-10, 09:59

Итак, речь шла о факторах, влияющих на количество багов в проектах и мерах их предотвращения.
А "обезьяна" - была метафорой к этому.
>>>Обезьяна же на танке безопасна.
>>
>>А как насчет обезьяны с гранатой? :)
>
>Ну если рассуждать с научной точки зрения, то вероятность того, что она грамотно оторвет чеку, после этого бросит в вас (и умудрится не подорваться сама) - вероятность маленькая)
То есть вы считате, что с научной точки зрения очень мала вероятность того, что примат сможет "грамотно оторвать чеку".
Это в метафоре прмерно соответствует способности представителей определенных течений в программировании написать код, который может запускаться.
Далее вы видимо считаете, что обезьяна с гранатой да еще и с оторванной чекой по прежнему не представляет большой опастности, и ей по-вашему надо ее еще именно бросить, чтобы создать эффект. А может ли она подорваться сама - это по-вашему вообще не важно.
С учетом того, что обезьяна - это метафора какбэ "специалиста", плохо владеющего инструментом, а взрыв - это метафора большого количества багов в проектах, с учетом этого ход ваших рассуждений очень даже характеризует. Особенно игнорирование опасности "самоподрыва".
>Хотя смотря какая обезъяна.
>Если на вас несется разъяренная горилла, то там пофиг на гранату)
И продолжение вашей мысли не менее интересно.
Далее, судя по всему, если попытаться вывести общий смысл из ваших сбивчивых формулировок - вы не согласны с тем, что количество багов в первую очередь зависит от качества проектирования.
>А с кодингом - 99% ошибок идут изза кривизны рук, и 1% - изза ошибок самого языка.
>Я бы даже сказал, что соотношение 99,99% и 0,01% =)
>Фишка ещё в том, что когда знаешь, что вон в том модуле, или вон в том операторе часто находят ошибки, можно написать код с оглядкой на это.
Интересно, что за такими "языками" вы предпочитаете пользоваться, в операторах которых "часто находят ошибки". И вмето того, чтобы отправить баг репорт об этом, фундаментально огораживают это место большим количеством "проверок".
И судя по всему, операторов в них не меньше, чем модулей.
>Т.е. поставить там побольше проверок данных, побольше проверок на error=1 и т.д.
Т.е. по-вашему, главное поставить "побольше проверок", а проектировать не обязательно.
А откуда у вас берутся проверочные условия, вы обычно не особо задумываетесь. А также какова вероятность неправильно поставить сами эти проверки.
>Т.е. руками уменьшить даже вероятность глюка изза ошибки языка.
>Обычно наоборот - это язык уменьшает вероятность глюка изза кривых рук)
Ну и наконец, вы явно путаете понятие языка со средсвами разработки.
Из всего вами сказанного, отчетливо виден общий стиль, в котором вы пишете. Это длинные-длинные тексты програм, с большим-большим количеством "проверок". И вы убеждены, что именно такой стиль фундаментально огораживает вас от большого числа багов.
А также можно пердположить, что вы пользуетесь средствами, которые такой стиль всячески поощряют, и создают иллюзию, что якобы можно обойтись и без проектирования.

Ответить | Правка | Наверх | Cообщить модератору

10. "Google предлагает переосмыслить подход к раскрытию информаци..." +/–

Сообщение от Аноним (-), 23-Июл-10, 10:23

Почему не вижу ? Не вижу только до выхода исправленной версии. Как только версия вышла обычно можно отследить историю определения дыр. И в самих advisory обычно приводится лог, дыра найдена тогда-то, тогда-то сообщено разработчикам, тогда-то поправлено, тогда-то информация придана огласке.

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

13. "Google предлагает переосмыслить подход к раскрытию информаци..." –1 +/–

Сообщение от ВДНХ (?), 23-Июл-10, 10:34

>Почему не вижу ?
Потому что у вас упрощенный и идеализированный взгляд на мир.
>Не вижу только до выхода исправленной версии. Как только версия вышла обычно можно отследить историю определения дыр. И в самих advisory обычно приводится лог, дыра найдена тогда-то, тогда-то сообщено разработчикам, тогда-то поправлено, тогда-то информация придана огласке.
А кто вам сказал, что все придается огласке?
Если цивилизованный способ сообщать об ошибках разработчикам, не придавая ошибки огласке. Тем не менее все довольны.

Ответить | Правка | Наверх | Cообщить модератору

50. "Google предлагает переосмыслить подход к раскрытию информаци..." +/–

Сообщение от ВДНХ (?), 23-Июл-10, 15:19

>> Если цивилизованный способ сообщать об ошибках разработчикам, не придавая ошибки огласке. Тем не менее все довольны.
^Есть^ цивилизованный способ сообщать об ошибках разработчикам, не придавая ошибки огласке. Тем не менее все довольны.

Ответить | Правка | Наверх | Cообщить модератору

Часть нити удалена модератором

85. "Google предлагает переосмыслить подход к раскрытию информаци..." +/–

Сообщение от XoRe (ok), 24-Июл-10, 14:28

>>>>Почему не вижу ?
>>>
>>>Потому что у вас упрощенный и идеализированный взгляд на мир.
>>
>>Клевый аргумент.
>>И не поспоришь - труднее всего спорить с глупым аргументом =)
>
>Ну, данный аргумент далее более подробно объясняется, и вы с этими объяснениями
>спорить не решились, посто вырвав фразу из общего контекста, и сферчно
>заявив о глупости в вакууме.
Это хорошо, если подробно объясняется.
А вы можете спорить с человеком, не стараясь его задеть (своими предположениями о его возможной низкой квалификации)?
Ну и плюс, не просто сотрясать воздух фразами "грамотное проектирование", "семантическая ошибка", и т.д.
А добавить конкретики.
Например, привести пример кода или пример проектирования, который доказывает вашу правоту.
Ещё можно ссылки приводить на конкретные статьи.
А то получается спор в виде "все вот так и вот так, а если вы не понимаете этого, то вы дилетант и дурак".
Конструктива и позитива.

Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

88. "Google предлагает переосмыслить подход к раскрытию информаци..." +/–

Сообщение от ВДНХ (?), 24-Июл-10, 15:10

>Ну и плюс, не просто сотрясать воздух фразами "грамотное проектирование", "семантическая ошибка", и т.д.
>А добавить конкретики.
Я вообще-то говорил о зависимости количества багов от качества проектирования.
А не сферическое "грамотное проектирование" в вакууме.
То есть для вас тема проектирования - не конкретна?
Сдается, что вы вообще плохо представляете себе, что это такое.
Вы не знаете, что такое "семантическая ошибка"? А это вы вообще к чему?
>Например, привести пример кода или пример проектирования, который доказывает вашу правоту.
Интересно, как вы представляете себе пример проектирования, размещенный здесь в форуме?
И что я потеряю, если факт моей правоты, конкретно вы посчитаете не доказанным?
>Ещё можно ссылки приводить на конкретные статьи.
На какие статьи? В уголовном кодексе? Как я могу привести ссылки на конкретнные стаьи, если я на конкретные стаьи не ссылался?
Вы обнаружили пробелы в своих знаниях, и хотите, чтобы я вам подсказал, как их восполнить?
При этом ставя ворос так, как будто я обязан заботиться о целостности ваших познаний.
>А то получается спор в виде "все вот так и вот так, а если вы не понимаете этого, то вы дилетант и дурак".
Я что-то потеряю, если у вас так получится?
Я говорил то, что я говорил.
Количество багов в проектах в первую очередь зависит от качества проектирования.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру


	7. "Google предлагает переосмыслить подход к раскрытию информаци..."	+/–
	Сообщение от ВДНХ (?), 23-Июл-10, 09:59
	> К сожалению работает только full disclosure, посмотрите последние выпуски PHP и Firefox, в PHP поправили дыры о которых приватно сообщили в мае, а в Firefox - в марте. Одновременно в Firefox почти мгновенно поправили дыру о которой стало известно публично. Как вы можете знать, работают ли другие способы, если вы их не видите? В том то и суть, чтобы было больше дела, и меньше зависеть от от пустых крикунов. Своевремменность нахождения и исправления ошибок зависит в первую очередь от качества архитектуры проекта. Если архитектура корявая - потом кричи, не кричи об ошибках - их будет море. Как это можно наблюдать с PHP.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	9. "Google предлагает переосмыслить подход к раскрытию информаци..."	–1 +/–
	Сообщение от klalafuda (?), 23-Июл-10, 10:16
	s/PHP/руками/g В руках мастера и палочки - оружие. Обезьяна же на танке безопасна.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	12. "Google предлагает переосмыслить подход к раскрытию информаци..."	+1 +/–
	Сообщение от ВДНХ (?), 23-Июл-10, 10:29
	>s/PHP/руками/g > >В руках мастера и палочки - оружие. Обезьяна же на танке безопасна. Да, если выбора не оказалось в конкретный момент. Однако, если выбор есть, то хороший мастер выбирает хороший инструмент. Хотя, я так понял, вы согласны со мной относительно низкого качества PHP. А сравнивать палочки и танк по качеству - нелогично. Вы явно путаете качество с размером и назначением. Могут быть качественные палочки и некачественный танк.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	14. "Google предлагает переосмыслить подход к раскрытию информаци..."	–7 +/–
	Сообщение от klalafuda (?), 23-Июл-10, 10:44
	Нет, Вы неправильно меня поняли. Я не согласен с Вами по поводу 'низкого качества PHP'. Это точно такой же инструмент, как и все остальные. Perl, Python, Ruby, you name. Ни чем от них не отличающийся. По крайней мере с точки зрения 'качества'. Поясню проще: с умом можно разрабатывать качественные продукты на любом из них. Кривыми же руками можно испортить абсолютно все, что угодно. И абстрактное 'качество' приведенного в качестве примера PHP тут совершенно не причем. Не стоит списывать дремучую некомпетентность отдельных конечных пользователей на проблемы инструмента.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	19. "Google предлагает переосмыслить подход к раскрытию информаци..."	+4 +/–
	Сообщение от ВДНХ (?), 23-Июл-10, 11:00
	>Нет, Вы неправильно меня поняли. Я не согласен с Вами по поводу 'низкого качества PHP'. Это точно такой же инструмент, как и все остальные. Perl, Python, Ruby, you name. Ни чем от них не отличающийся. По крайней мере с точки зрения 'качества'. То, что вы ставите в одну линию PHP, Perl, Python и Ruby по качеству архитектуры, может говорить только о том, что вы плохо представляете себе архитектуру ПО и процессы проектирования. >Поясню проще: с умом можно разрабатывать качественные продукты на любом из них. Разрабатывать-то можно, но только не с умом. Продукт может и будет одинакового качества, но себестоимость его производства с помощью инструментов разного качества будет тоже разной. Таких простых вещей не знаете. А еще говорите о компетентности. >Кривыми же руками можно испортить абсолютно все, что угодно. И абстрактное 'качество' приведенного в качестве примера PHP тут совершенно не причем. Не стоит списывать дремучую некомпетентность отдельных конечных пользователей на проблемы инструмента. Поздно метаться. Вы сравнивали до этого по качеству танк и палочки. А ваши поздние оправдания по поводу плохого качества ваших мыслей - сродни тем самым выкрикам о больших количествах найденных и исправленных ошибках, когда качество проектирования было плохим изначально.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	54. "Google предлагает переосмыслить подход к раскрытию информаци..."	+/–
	Сообщение от Crazy Alex (??), 23-Июл-10, 16:05
	Да понятно, что PHP не без недостатков, но всё же это далеко не бейсик. Писать на нём хорошо можно, он этому не мешает особо. Не навязывает - это да, но не мешает. Если, конечно, вы не PHP3 имеете в виду, с register_globals, magic quotes, без ООП и пространств имён.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	56. "Google предлагает переосмыслить подход к раскрытию информаци..."	+3 +/–
	Сообщение от ВДНХ (?), 23-Июл-10, 16:36
	>Да понятно, что PHP не без недостатков, но всё же это далеко не бейсик. Ну если вы можете сравнить только с бейсиком - то конечно. >Писать на нём хорошо можно, он этому не мешает особо. Писать и на бумаге хорошо можно, она тоже этому не мешает особо. >Не навязывает - это да, но не мешает. Этим интересным противопоставлением вы как бы пытаетесь нам сказать, что вам даже тех навязываний, которые есть в PHP не достаточно, но зато вас утешает, что он вам "не мешает особо". Вообще очень даже много чего навязывает, как многие более примитивнные языки. Хотя примитивные языки и должны навязывать - стиль, методы решения и др. - в этом их назначение, своеобразная "защита от дурака". Но ведь речь шла именно о качестве реализации, а это совсем другое. Потому что будучи рожденным, как узко-специализированное средство для веб-разработок, PHP пытается изображать из себя язык общего назначения. А в итоге - "не пава, не ворона". И куча хаотичных заплат во внутренней архитектуре. Плюс еще плохое начальное проектирование даже как узко-специализированного средства. И комьюнити такое же. Интересно, на каких тогда языках вам "плохо писать", и какие языки вам "танцевать^W писать мешают"? >Если, конечно, вы не PHP3 имеете в виду, с register_globals, magic quotes, без ООП и пространств имён. Понятно одно. Вы тоже один из тех, кто плохо представляет себе, что такое архитектура ПО и качество проектирования. И руководствуетесь преимущественно такими туманными критериями, как "на нем хорошо писать", типа "хорошо сидим".
	Ответить \| Правка \| Наверх \| Cообщить модератору


	29. "Google предлагает переосмыслить подход к раскрытию информаци..."	+3 +/–
	Сообщение от Аноним (-), 23-Июл-10, 12:22
	>Поясню проще: с умом можно разрабатывать качественные продукты на любом из них. >Кривыми же руками можно испортить абсолютно все, что угодно. И абстрактное >'качество' приведенного в качестве примера PHP тут совершенно не причем. Не стоит >списывать дремучую некомпетентность отдельных конечных пользователей на проблемы >инструмента. не верно. вы и все-все окружающие могут ездить на машинах всегда по правилам, но если вдруг у вашей машины откажут тормоза, то совершенно не очевидно, что вы не соберете впереди едущего.
	Ответить \| Правка \| К родителю #14 \| Наверх \| Cообщить модератору


	41. "Google предлагает переосмыслить подход к раскрытию информаци..."	+/–
	Сообщение от Michael Shigorin (ok), 23-Июл-10, 14:04
	>PHP [...] Perl, Python, Ruby, you name. Ни чем от них не отличающийся. >По крайней мере с точки зрения 'качества'. Как полагаете -- руки, которыми такое пишется, как можно назвать?.. :( PS: такое ощущение, что выгорели и устали от проблем "здеся". Не переживайте, тоже порой бывает, но в итоге когда понимаешь, что диагностируемость всё-таки милее -- всё возвращается на круги своя :)
	Ответить \| Правка \| К родителю #14 \| Наверх \| Cообщить модератору


	46. "Google предлагает переосмыслить подход к раскрытию информаци..."	+/–
	Сообщение от User294 (ok), 23-Июл-10, 14:30
	>Обезьяна же на танке безопасна. А как насчет обезьяны с гранатой? :)
	Ответить \| Правка \| К родителю #9 \| Наверх \| Cообщить модератору


	72. "Google предлагает переосмыслить подход к раскрытию информаци..."	–2 +/–
	Сообщение от XoRe (ok), 23-Июл-10, 20:43
	>>Обезьяна же на танке безопасна. > >А как насчет обезьяны с гранатой? :) Ну если рассуждать с научной точки зрения, то вероятность того, что она грамотно оторвет чеку, после этого бросит в вас (и умудрится не подорваться сама) - вероятность маленькая) Хотя смотря какая обезъяна. Если на вас несется разъяренная горилла, то там пофиг на гранату) А с кодингом - 99% ошибок идут изза кривизны рук, и 1% - изза ошибок самого языка. Я бы даже сказал, что соотношение 99,99% и 0,01% =) Фишка ещё в том, что когда знаешь, что вон в том модуле, или вон в том операторе часто находят ошибки, можно написать код с оглядкой на это. Т.е. поставить там побольше проверок данных, побольше проверок на error=1 и т.д. Т.е. руками уменьшить даже вероятность глюка изза ошибки языка. Обычно наоборот - это язык уменьшает вероятность глюка изза кривых рук)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	81. "Google предлагает переосмыслить подход к раскрытию информаци..."	+/–
	Сообщение от ВДНХ (?), 24-Июл-10, 09:59
	Итак, речь шла о факторах, влияющих на количество багов в проектах и мерах их предотвращения. А "обезьяна" - была метафорой к этому. >>>Обезьяна же на танке безопасна. >> >>А как насчет обезьяны с гранатой? :) > >Ну если рассуждать с научной точки зрения, то вероятность того, что она грамотно оторвет чеку, после этого бросит в вас (и умудрится не подорваться сама) - вероятность маленькая) То есть вы считате, что с научной точки зрения очень мала вероятность того, что примат сможет "грамотно оторвать чеку". Это в метафоре прмерно соответствует способности представителей определенных течений в программировании написать код, который может запускаться. Далее вы видимо считаете, что обезьяна с гранатой да еще и с оторванной чекой по прежнему не представляет большой опастности, и ей по-вашему надо ее еще именно бросить, чтобы создать эффект. А может ли она подорваться сама - это по-вашему вообще не важно. С учетом того, что обезьяна - это метафора какбэ "специалиста", плохо владеющего инструментом, а взрыв - это метафора большого количества багов в проектах, с учетом этого ход ваших рассуждений очень даже характеризует. Особенно игнорирование опасности "самоподрыва". >Хотя смотря какая обезъяна. >Если на вас несется разъяренная горилла, то там пофиг на гранату) И продолжение вашей мысли не менее интересно. Далее, судя по всему, если попытаться вывести общий смысл из ваших сбивчивых формулировок - вы не согласны с тем, что количество багов в первую очередь зависит от качества проектирования. >А с кодингом - 99% ошибок идут изза кривизны рук, и 1% - изза ошибок самого языка. >Я бы даже сказал, что соотношение 99,99% и 0,01% =) >Фишка ещё в том, что когда знаешь, что вон в том модуле, или вон в том операторе часто находят ошибки, можно написать код с оглядкой на это. Интересно, что за такими "языками" вы предпочитаете пользоваться, в операторах которых "часто находят ошибки". И вмето того, чтобы отправить баг репорт об этом, фундаментально огораживают это место большим количеством "проверок". И судя по всему, операторов в них не меньше, чем модулей. >Т.е. поставить там побольше проверок данных, побольше проверок на error=1 и т.д. Т.е. по-вашему, главное поставить "побольше проверок", а проектировать не обязательно. А откуда у вас берутся проверочные условия, вы обычно не особо задумываетесь. А также какова вероятность неправильно поставить сами эти проверки. >Т.е. руками уменьшить даже вероятность глюка изза ошибки языка. >Обычно наоборот - это язык уменьшает вероятность глюка изза кривых рук) Ну и наконец, вы явно путаете понятие языка со средсвами разработки. Из всего вами сказанного, отчетливо виден общий стиль, в котором вы пишете. Это длинные-длинные тексты програм, с большим-большим количеством "проверок". И вы убеждены, что именно такой стиль фундаментально огораживает вас от большого числа багов. А также можно пердположить, что вы пользуетесь средствами, которые такой стиль всячески поощряют, и создают иллюзию, что якобы можно обойтись и без проектирования.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	10. "Google предлагает переосмыслить подход к раскрытию информаци..."	+/–
	Сообщение от Аноним (-), 23-Июл-10, 10:23
	Почему не вижу ? Не вижу только до выхода исправленной версии. Как только версия вышла обычно можно отследить историю определения дыр. И в самих advisory обычно приводится лог, дыра найдена тогда-то, тогда-то сообщено разработчикам, тогда-то поправлено, тогда-то информация придана огласке.
	Ответить \| Правка \| К родителю #7 \| Наверх \| Cообщить модератору


	13. "Google предлагает переосмыслить подход к раскрытию информаци..."	–1 +/–
	Сообщение от ВДНХ (?), 23-Июл-10, 10:34
	>Почему не вижу ? Потому что у вас упрощенный и идеализированный взгляд на мир. >Не вижу только до выхода исправленной версии. Как только версия вышла обычно можно отследить историю определения дыр. И в самих advisory обычно приводится лог, дыра найдена тогда-то, тогда-то сообщено разработчикам, тогда-то поправлено, тогда-то информация придана огласке. А кто вам сказал, что все придается огласке? Если цивилизованный способ сообщать об ошибках разработчикам, не придавая ошибки огласке. Тем не менее все довольны.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	50. "Google предлагает переосмыслить подход к раскрытию информаци..."	+/–
	Сообщение от ВДНХ (?), 23-Июл-10, 15:19
	>> Если цивилизованный способ сообщать об ошибках разработчикам, не придавая ошибки огласке. Тем не менее все довольны. ^Есть^ цивилизованный способ сообщать об ошибках разработчикам, не придавая ошибки огласке. Тем не менее все довольны.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	85. "Google предлагает переосмыслить подход к раскрытию информаци..."	+/–
	Сообщение от XoRe (ok), 24-Июл-10, 14:28
	>>>>Почему не вижу ? >>> >>>Потому что у вас упрощенный и идеализированный взгляд на мир. >> >>Клевый аргумент. >>И не поспоришь - труднее всего спорить с глупым аргументом =) > >Ну, данный аргумент далее более подробно объясняется, и вы с этими объяснениями >спорить не решились, посто вырвав фразу из общего контекста, и сферчно >заявив о глупости в вакууме. Это хорошо, если подробно объясняется. А вы можете спорить с человеком, не стараясь его задеть (своими предположениями о его возможной низкой квалификации)? Ну и плюс, не просто сотрясать воздух фразами "грамотное проектирование", "семантическая ошибка", и т.д. А добавить конкретики. Например, привести пример кода или пример проектирования, который доказывает вашу правоту. Ещё можно ссылки приводить на конкретные статьи. А то получается спор в виде "все вот так и вот так, а если вы не понимаете этого, то вы дилетант и дурак". Конструктива и позитива.
	Ответить \| Правка \| К родителю #81 \| Наверх \| Cообщить модератору


	88. "Google предлагает переосмыслить подход к раскрытию информаци..."	+/–
	Сообщение от ВДНХ (?), 24-Июл-10, 15:10
	>Ну и плюс, не просто сотрясать воздух фразами "грамотное проектирование", "семантическая ошибка", и т.д. >А добавить конкретики. Я вообще-то говорил о зависимости количества багов от качества проектирования. А не сферическое "грамотное проектирование" в вакууме. То есть для вас тема проектирования - не конкретна? Сдается, что вы вообще плохо представляете себе, что это такое. Вы не знаете, что такое "семантическая ошибка"? А это вы вообще к чему? >Например, привести пример кода или пример проектирования, который доказывает вашу правоту. Интересно, как вы представляете себе пример проектирования, размещенный здесь в форуме? И что я потеряю, если факт моей правоты, конкретно вы посчитаете не доказанным? >Ещё можно ссылки приводить на конкретные статьи. На какие статьи? В уголовном кодексе? Как я могу привести ссылки на конкретнные стаьи, если я на конкретные стаьи не ссылался? Вы обнаружили пробелы в своих знаниях, и хотите, чтобы я вам подсказал, как их восполнить? При этом ставя ворос так, как будто я обязан заботиться о целостности ваших познаний. >А то получается спор в виде "все вот так и вот так, а если вы не понимаете этого, то вы дилетант и дурак". Я что-то потеряю, если у вас так получится? Я говорил то, что я говорил. Количество багов в проектах в первую очередь зависит от качества проектирования.
	Ответить \| Правка \| Наверх \| Cообщить модератору