[Security-team] security-team policy
Vladimir Lettiev
thecrux на gmail.com
Вт Апр 28 09:08:53 MSD 2009
28 апреля 2009 г. 1:27 пользователь Dmitry V. Levin <ldv@> написал:
> On Mon, Apr 27, 2009 at 11:16:22AM +0400, Vladimir Lettiev wrote:
>
> CVE является базой данных, куда в конечном итоге стекается информация обо
> всех зарегистрированных уязвимостях в ПО. Однако рассматривать CVE в
> качестве источника информации о _новых_ уязвимостях в ПО совершенно
> нереально из-за латентности.
лучше поздно, чем никогда. slackware, например, недавно закрыла дыры
2-х летней давности.
>> Другие источники (возможно вторичные):
>
> + Важным публичным источником информации (как вторичной, так и первичной)
> является oss-security на lists.openwall.com
да, это тоже надо отслеживать
> + Кроме того, ещё есть и непубличные источники первичной информации,
> они же места, где договариваются о CRD.
Что тут скажешь, это большая удача, если знаешь о проблеме до публичного анонса.
...
> А чего не хватает в багзилле? Может быть, прикрутить к ней будет проще?
Предположим обнаружена уязвимость в пакете foo. foo присутствует в
sisyphus, и во всех поддерживаемых бранчах. Как мне повесить баг на
всех этих foo? Вдруг выясняется, что из исходников foo собираются
бинарные пакеты libfoo и foo-tools, каждый из которых уязвим, на кого
повесить баг?
Нужен хотя бы какой-то посреднический инструмент, который по имени src
пакета выстрелит в багзиллу набором багов по всем реинкарнациям foo +
сделает один мета-баг на сущность "security", зависяший от всех
остальных багов.
Опять же нужен инструмент, который бы сформировал человеческий
security advisory по данным внесённым в багзиллу.
Или я всё усложняю?
--
Vladimir Lettiev aka crux <theCrux на gmail.com>
Подробная информация о списке рассылки Security-team