[devel] severity "security"

[Michael Shigorin]

On Mon, Oct 02, 2006 at 08:10:09PM +0300, Andrew Kornilov wrote:
> >Пойдите на http://cve.mitre.org/cve/ и посмотрите.
> Там не всё. Вот только что приехала уязвимость на OpenVPN: DoS,
> System Access; на mitre.org её нет. Что мне делать? Ждать,
> когда об этом узнает майнтейнер, повесить баг, пересобрать
> самому?

Уведомить майнтейнера, пересобрать самому и закинуть в
/incoming/updates, если заработало (если есть тесткейс
-- соответственно проверив им).

> >Либо я вас не понял, либо вы наивно полагаете, что дырявость
> >пакета так же легко проверяется, как и собираемость.
> Неплохо бы иметь список проблем из разных источников, чтобы не
> метаться по всем рассылкам.

Подпишись на рассылку secunia.com, вполне адекватно IMHO.
Ну и раз озадачился -- на security-team на .

> >>>>Но ситуацию с security, похоже, никто не отслеживает совершенно.
> >>>Ну, тут вы сильно заблуждаетесь. :)
> >>Я очень на это надеюсь. Но очень хочется увидеть какие-либо
> >>упоминания об этом, а еще лучше результаты.
> >Я определённо не понимаю, какое упоминание и какой результат
> >вы хотите увидеть.
> К примеру, оповещение где-либо о том, что исправлены такие-то
> ошибки и доступны новые пакеты. Как это было раньше для пакетов
> из коробочных дистрибутивов (и есть ли оно сейчас для них?).
> Все это достаточно не сложно автоматизировать, если захотеть :)

Для этого требуются:

- security response team (на ставке или добровольная);
- (желательно) тестировщики исправлений;
- (желательно) писатели анонсов или 
- внятные changelog и робот-чтец к ним.

Для Sisyphus мне кажется осмысленным разве что нечто
дебиановского urgency в changelog добавлять каким-то
единообразным макаром.

> Майнтейнер майнтейнеру рознь. Ведь они это не за зарплату
> делают и это не их основная задача. Кому-то все равно, есть ли
> remote access к этому приложению, потому как у него и сети нет
> на этой машине и пользуется он один этим. А кто-то использует
> это по полной программе. Причем, майнтейнер может быть вообще в
> астрале и не реагировать на письма. Что делать второму?
> Постоянно следить за пакетом, не надеясь на первого и при
> первой же уязвимости делать NMU? Понятно, что вариантов масса и
> всего учесть нельзя.

Вот для чего big incoming lock и надо решать, в частности.
Поскольку порой одни заинтересованы в развитии и поддержании
функциональности пакета, а другие -- безопасности, и без
доступной по цене (времени) возможности сотрудничать это 
не работает.

> >>p.s. Я повторю вопрос: что будет после "заморозки" среза
> >>Сизифа? Будет ли кто-нибудь анализировать срез на предмет
> >>безопасности?
> >Не думаю, что имеет смысл "анализировать срез на предмет
> >безопасности".  Надо просто следить за своими пакетами.
> >P.S. Всех учу, а самому никак libtiff новый собрать некогда. :(
> А как можно за ними за всеми следить? Вот только что глянул на
> Top maintainers на sisyphus.ru (все знают, кто там :). В жизни
> не поверю, что кто-то из них физически способен следить за
> своими пакетами, даже если он этим будет заниматься 24/7 :)
> А вот если коллективно, то хоть что-то получится.

Мне кажется, может помочь институт лейтенантов -- в плане
"собрать свежую версию, благо ничего притирать особо не надо",
"закинуть патчи в апстрим", "подстраховать по сборке апдейта".

Вот только где брать ответственных студентов, которые достаточно
сильно дружат с головой, чтобы ценить такой экспириенс нахаляву
-- пока не совсем понятно.

> p.s. В общем, это всё лирика пока, конечно. Но что-то полезное
> и интересное придумать можно, если не быть столь консервативным
> :) Чукча, к сожалению, больше читатель, чем писатель, поэтому
> от меня конструктива дождаться сложно. Может кто присоединится.

Давай для начала поддержим инициативу Димы насчёт git.alt руками.
Это часть решения блокировки распределённой работы.

-- 
 ---- WBR, Michael Shigorin <mike на altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/