sec updates (was: [room] ALT)

[Maxim Tyurin]

Michael Shigorin writes:

> On Mon, Nov 14, 2005 at 08:40:37PM +0300, Денис Смирнов wrote:
>> MT> Период жизни не меньше 3-х лет.
>
> Со средами сборки это реально, но у нас, например, на сейчас
> нет настолько старых систем. (понятно, что их появление при
> нормальном подходе -- дешевле, чем гонка обновлений)

А у меня есть. Если есть сервер и задачи его не изменились то смысла
его обновлять я не вижу. 
Если стоит у меня Woody и делает все что надо то не буду я его
обновлять пока поддержка Woody не закончится.

>> MT> Насколько часто вопрос более сложный. Мне хватает раз в 2 года.
>> Ясно. То есть при таком режиме одновременно необходимо
>> поддерживать не более двух веток, причём одну из них можно
>> в виде "security fixes and critical bugfix only".
>
> Угу.  Но с прочерченными сроками ожидаемого окончания поддержки,
> если речь не только о "своём цеху".  Для себя-то хоть с закрытия
> известных проблем начать, а там уж по оценке усилий выводы делать.
>
>> Этого, вместе с наличием в updates фиксов к свежим багам
>> достаточно?
>
> С этого надо начинать.  Дима говорит, что с координацией
> sec team поможет, если люди хорошие будут.

Не только security. Незаслуженно забытый errata тоже обязателен. 

> Собственно, мы попытались (с моей недожареной подачи)
> организовать такой процесс; первая организованная пачка
> обновлений по диминой сводке открытых проблем (выбрав наиболее
> критичные IIRC) с сопутствующими анонсами была подписана 
> "при поддержке EMT", чего в опубликованных анонсах не было.
>
> Возобновление работ нашего народу именно по апдейтам
> целенаправленно с тех пор не произошло; хотя дело не
> в наивной рекламе именно себя, просто апдейты -- вещь
> сугубо неинтересная, выгребная яма своего рода.
>
> Соответственно Дима вполне мог писать "спонсировано
> Димой Левиным", и это было бы 1) честно; 2) указывало 
> на возможность получить лишнее внимание такой работой.
>
> Короче говоря, на сейчас если строить здесь более общественную
> инфраструктуру -- получается
>
> - security-team@ как рассылка (сейчас алиас);
> - перебраться туда теми, кто:
>   + отслеживает проблемы и может быстрее проинформировать о них,
>     чем майнтейнер узнает сам;
>   + является майнтейнером, поддерживающим свои пакеты и в stable;
>   + является заинтересованным в заткнутости дырок в используемых
>     пакетах, в т.ч. других сборщиков (на момент выпуска/текущий);
> - попросить Диму составить список текущих нерешённых критичных
>   проблем в ALM2.4+updates;

Если бы такой список регулярно падал в security-team@ то от него был
бы толк и не загнулся бы он ИМХО.

> - проверить наличие [попыток] решений в backports/2.4 и их
>   пригодность;
> - приступить к разгребанию обретённого счастья, благо во многих
>   случаях патчи уже доступны (выковыриваются из RHEL или Debian);
> - при уверенности в отсутствии регрессов в пакете вливать
>   в /i/u/2.4, иначе с описанием подозрительных мест --
>   в /i/b/2.4 с тем, чтобы через несколько дней тестирования 
>   рекомендовать перекладывание в u/M/2.4 или отзыв;
> - напустить на /u/M/2.4 робота по чтению вслух changelog'ов
>   в security-announce@, уж если человеческого слова не хватает.
>   Соответственно мои changelog'и уже довольно давно для этого 
>   готовы.

Вот робот такой нужен. И пусть пишет в рассылку security@
Только желательно формализировать записи в changelog.

>
> PS: пошли в devel@?

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

With Best Regards, Maxim Tyurin
JID:	MrKooll на jabber.pibhe.com
   ___                                 
  / _ )__ _____  ___ ____ _______ _____
 / _  / // / _ \/ _ `/ _ `/ __/ // (_-<
/____/\_,_/_//_/\_, /\_,_/_/  \_,_/___/
               /___/