From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: To: community@altlinux.ru Subject: Re: [Comm] Re: =?koi8-r?b?4sXaz9DB087P09TY?= References: <20041224121731.GA26993@osdn.org.ua> <20041225182002.GA12147@mithraen_ws> <20041229220246.GB19669@basalt.office.altlinux.org> <20041230110914.GC5565@mithraen.dimline.ru> <20041230111559.GB10607@basalt.office.altlinux.org> <20041230153234.GY3142@osdn.org.ua> <20041230162337.GA24072@basalt.office.altlinux.org> <20041230181458.GA12052@mithraen.dimline.ru> <20041230205949.GA26564@basalt.office.altlinux.org> <20050102204747.GA22062@basalt.office.altlinux.org> From: Dmitry Derjavin Date: Tue, 04 Jan 2005 03:06:41 +1000 In-Reply-To: <20050102204747.GA22062@basalt.office.altlinux.org> (Dmitry V. Levin's message of "Sun, 2 Jan 2005 23:47:47 +0300") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit X-BeenThere: community@altlinux.ru X-Mailman-Version: 2.1.5 Precedence: list Reply-To: community@altlinux.ru List-Id: Mailing list for ALT Linux users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2005 17:06:42 -0000 Archived-At: List-Archive: List-Post: On Mon, Jan 03 2005 at 06:47, "Dmitry V. Levin" wrote: >> > По сути ничего не изменилось. Просто объём поддерживаемой базы >> > вырос в несколько раз, преимущественно за счёт потенциально более >> > уязвимого кода, соответственно, объём выпускаемых обновлений тоже >> > вырос. >> >> Ну и что? По-моему, это совершенно типичная ситуация, которая решается >> на уровне менеджмента. > > Или не решается. :) Это тоже типичная ситуация. :) >> А вовсе не на уровне аудита кода или подготовки обновлений. > > И на этом уровне тоже. Нет, не на этом. Тут что-то из серии мух и котлет: сначала, видимо, имеет смысл сформулировать проблему, максимально абстрагировавшись от деталей производственного процесса. "Есть некое производство, объём которого постоянно растёт, в связи с чем имеющихся ресурсов становится недостаточно для поддержания качества на прежнем уровне" -- как-то так. И решать эту проблему, по-моему, нужно как раз в подобной формулировке, и уже менеджерам производственного процесса, а не программистам, которые, я подозреваю, пытаются её сейчас решить. >> > Пришлось чем-то пожертвовать. Лучше уж сократить выпуск >> > анонсов, чем выпуск обновлений, хотя и он тоже неизбежно >> > сокращается. >> >> Не лучше, а гораздо хуже -- уверяю вас. Особенно в связи с тем, что >> сокращается выпуск обновлений. Думаю, что именно с точки зрения >> безопасности гораздо правильнее в такой ситуации сосредоточиться на >> подготовке анонсов. В этом случае те же админы сэкономят кучу >> времени, если будут точно знать, уязвима конкретная сборка или нет. > > Я не умею сочинять анонсы к незафиксенным уязвимостям. И не хочу > уметь. Имелось в виду примерно следующее: http://lists.altlinux.ru/pipermail/security-announce/2001-March/000001.html http://lists.altlinux.ru/pipermail/security-announce/2003-September/000187.html На этой кожуре от банана отпечатки ваших зубов, Дмитрий. ;) >> А обновление можно будет подготовить средствами сообщества. Как, >> например, и получилось недавно во время совершенно безобразного, на >> мой взгляд, инцидента с php. > > По-моему, с php давно всё плохо. Могу назвать ещё несколько таких > пакетов, которые со временем уходят (или не уходят, хоть и должны) в > contrib из-за неподдерживаемости. Вы, думаю, тоже. Что "тоже" -- в contrib? :) А если серьёзно -- по-моему, php это один из важнейших элементов современного web-сервера. И если дистрибутив позиционируется как серверный, то в contrib такому пакету никак нельзя. И не важно при этом, "хорошо" с ним или "плохо". Нужно сделать, чтобы стало хорошо. > Что касается подготовки обновлений средствами сообщества, то я готов > это направление поддерживать, как наиболее естественное в > сложившейся ситуации. Замечательная новость. Предлагаю начать с официального объявления, в котором бы однозначно оговаривалась сфера ответственности Security Team. >> Давайте пока не будем. Во всяком случае, пока Security Team таким >> странным образом расставляет приоритеты.. > > Я убеждён, что исправление важнее анонса. Сисадмин в состоянии > проанализировать степень угрозы скорее, чем подготовить исправление. А ещё он должен быть в состоянии оценить заранее затраты своего времени и их примерную стоимость. Представьте себе такую ситуацию: в Bugtraq появляется информация об уязвимости, при этом Security Team молча готовит обновление. По "независящим причинам" подготовка затягивается. Но в силу некоторых особенностей altlinux риск использования именно этой уязвимости на дистрибутивах altlinux минимален. Админ оценивает (справедливо), что на то, чтобы убедиться, что риск действительно минимален, ему потребуется гораздо большее время, чем потенциальному злоумышленнику на взлом. И готовит обновление самостоятельно. Через некоторое время выходит официальное обновление, уже никому не нужное. В результате потрачено время на подготовку двух бесполезных обновлений. При этом, чтобы избежать потерь времени, достаточно было бы вовремя опубликовать маленький анонс. Таким образом, отсутствие анонсов приводит к гораздо большим затратам времени, чем отсутствие обновлений. Достаточно ли это убедительный пример? -- ~dd