On Tue, Jan 04, 2005 at 03:06:41AM +1000, Dmitry Derjavin wrote:
[...]
> Это тоже типичная ситуация. :)
> 
> >> А вовсе не на уровне аудита кода или подготовки обновлений.
> >
> > И на этом уровне тоже.
> 
> Нет, не на этом. Тут что-то из серии мух и котлет: сначала, видимо,
> имеет смысл сформулировать проблему, максимально абстрагировавшись от
> деталей производственного процесса. "Есть некое производство, объём
> которого постоянно растёт, в связи с чем имеющихся ресурсов становится
> недостаточно для поддержания качества на прежнем уровне" -- как-то
> так. И решать эту проблему, по-моему, нужно как раз в подобной
> формулировке, и уже менеджерам производственного процесса, а не
> программистам, которые, я подозреваю, пытаются её сейчас решить.

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

> >> > Пришлось чем-то пожертвовать.  Лучше уж сократить выпуск
> >> > анонсов, чем выпуск обновлений, хотя и он тоже неизбежно
> >> > сокращается.
> >> 
> >> Не лучше, а гораздо хуже -- уверяю вас. Особенно в связи с тем, что
> >> сокращается выпуск обновлений. Думаю, что именно с точки зрения
> >> безопасности гораздо правильнее в такой ситуации сосредоточиться на
> >> подготовке анонсов. В этом случае те же админы сэкономят кучу
> >> времени, если будут точно знать, уязвима конкретная сборка или нет.
> >
> > Я не умею сочинять анонсы к незафиксенным уязвимостям.  И не хочу
> > уметь.
> 
> Имелось в виду примерно следующее:
> 
> http://lists.altlinux.ru/pipermail/security-announce/2001-March/000001.html
> http://lists.altlinux.ru/pipermail/security-announce/2003-September/000187.html
> 
> На этой кожуре от банана отпечатки ваших зубов, Дмитрий. ;)

Ну, надписи типа сентябрьской можно отсылать по cron'у. :)

> >> А обновление можно будет подготовить средствами сообщества. Как,
> >> например, и получилось недавно во время совершенно безобразного, на
> >> мой взгляд, инцидента с php.
> >
> > По-моему, с php давно всё плохо.  Могу назвать ещё несколько таких
> > пакетов, которые со временем уходят (или не уходят, хоть и должны) в
> > contrib из-за неподдерживаемости.  Вы, думаю, тоже.
> 
> Что "тоже" -- в contrib? :)
> 
> А если серьёзно -- по-моему, php это один из важнейших элементов
> современного web-сервера. И если дистрибутив позиционируется как
> серверный, то в contrib такому пакету никак нельзя. И не важно при
> этом, "хорошо" с ним или "плохо". Нужно сделать, чтобы стало хорошо.

mod_php неисправим.  Те, кто его используют, должны знать, что они
постоянно рискуют нарваться на проблемы такого рода.  У меня есть
основания полагать, что blackhat community давно эксплуатирует ошибки в
mod_php и не стремится их публиковать.

> > Что касается подготовки обновлений средствами сообщества, то я готов
> > это направление поддерживать, как наиболее естественное в
> > сложившейся ситуации.
> 
> Замечательная новость. Предлагаю начать с официального объявления, в
> котором бы однозначно оговаривалась сфера ответственности Security
> Team.

Лучше начать с определения этой сферы. :)

> >> Давайте пока не будем. Во всяком случае, пока Security Team таким
> >> странным образом расставляет приоритеты..
> >
> > Я убеждён, что исправление важнее анонса.  Сисадмин в состоянии
> > проанализировать степень угрозы скорее, чем подготовить исправление.
> 
> А ещё он должен быть в состоянии оценить заранее затраты своего
> времени и их примерную стоимость.
> 
> Представьте себе такую ситуацию:
[...]
> Достаточно ли это убедительный пример?

Такое было хоть раз в истории?  Или только могло быть?


-- 
ldv