[devel] P: security volunteam

[Stanislav Ievlev]

On Wed, Jan 19, 2005 at 05:58:24PM +0200, Michael Shigorin wrote:
> On Wed, Jan 19, 2005 at 04:01:02PM +0300, vserge wrote:
> > Уважаемые коллеги:
> > 1) Надо ли нам определить Security policy 
> > 2) Надо ли расширить Security Team
> > 3) Как должна работать Security Team и что будет входить в ее
> > обязанности?
> 
> По предварительному обсуждению конца прошлого года могу
> предложить такое.
> 
> Желающие поднимают руку и собираются в security volunteers team,
> которая координируется security team и по возможности
> обеспечивает по возможности оперативный выпуск рекомендаций по
> обновлению для (хотя бы) последнего стабильного выпуска.
> 
> Что ожидается от участников -- заинтересованность в результате.
> Поэтому, как правило, это системные администраторы, использующие
> эти пакеты и системы в боевых условиях.
> 
> Что ожидается от sec team (в лице Димы) -- одобрение кандидатов в
> такую команду (скорее номинальное -- с учётом ограничения
> выборкой из участников ALT Linux Team?), маршрутизация информации
> об уязвимостях (конкретному майнтейнеру или всей команде);
> возможно, отслеживание статуса проблем (если на это не найдётся
> желающего побыть таким project manager).
Тут есть два "но" (но не "нет" ;) )
1. Одобрение не может быть "номинальным" ибо маршрутизация информации об
уязвимостях может идти только к достаточно компетентным и доверенным
лицам. Зачастую эта информация носит строго конфиденциальных характер.
Соответственно должны быть сформулированы определённые требования
к желающим. В частности, это не должны быть недавно подключившиеся к
проекту люди. Надеюсь Дима сможет хотя бы примерно сформулировать эти
требования.
2. С volunteers ничего нельзя требовать: как своевременного выпуска
обновлений так и соблюдения режима неразглашения информации.

В связи с этим мне кажется струтура security team должна быть достаточно
сложной и иерархической. Должно быть чётко определено взаимодействие между
мантейнерами и тем кто выпускает обновления (чтобы не было потом каких-либо взаимных претензий и лишних ссор), а также мера ответственности.
Должно быть ясно к кому пользователи предъявляют претензии в случае
некорректно собранного обновления.

Например, большая часть уязвимостей носит публичный характер и работа по
исправлению чисто механическая. Но есть категория пакетов, исправления к
которым готовятся достаточно долго и непублично.

Для начала, в качестве эксперимента security volunteers team, может
заняться выпуском давно пропущенных обновлений, а также обновлениями по
пакетам официально не поддерживаемым. Думаю, что мы сможем составить такой
список пакетов.

Дима, что скажешь?

--
Стас.