[devel] Vulnerability policy

[Igor Zubkov]

2017-02-21 21:09 GMT+02:00 Dmitry Derjavin:
> Вт, 21 фев 2017, 20:49, Anton Farygin:
>
>> 21.02.2017 20:29, lineprinter пишет:
>>> Назрела необходимость в https://www.altlinux.org/Vulnerability_Policy
>>> для security-tracker'а, которого еще нет. Предлагаю обсудить.
>>
>> Странно общаться в devel с принтером, пусть он даже line и очень быстр.
>> Предлагаю начать обсуждение с этого ;)
>
> Поддерживаю. Тема обсуждения, кстати, намекает на более ответственное
> отношение к идентификации.
>
> По теме: чем «security-tracker, которого еще нет» будет отличаться от
> того, который уже есть?
>
>> https://packages.altlinux.org/en/Sisyphus/security
>
> Или это не security-tracker?

Это не security, это не tracker, это просто позорная выборка из базы
которая сильно тормозит. На ней даже нет RSS. /security лучше убрать с
сайта и не позорится, чем что-то делать.

Правильный security tracker должен что делать:
1. Выгребать из записей %changelog все упоминания по поводу CVE и
таких же индентификаторов от самих разработчиков. Как пример,
phpMyAdmin. У них используется своя система трекания дыр и они нумерую
их как PMASA. У руби сообщества есть ruby-advisory-db.
2. Импортировать с http://www.cve.mitre.org список всех CVE.
3. Импортировать с других мест данные о проблемах с безопасностью. Тот же PMASA.
4. Линковать релиз пакета с списком проблем которые были исправлены в
релизе с CVE и иже с ним.
5. Дальше можно показывать сырой список того что было найдено в
%changelog пакетов
6. Можно и нужно, наверно, менеджить список того что над залетело из
каталога CVE (и других). Как пример, есть проблемы которым наше ядро
может быть не подвержено в силу того что оно было собрано не так.
7. Можно на основе этой информации писать Security Advisories и слать
из в security@ почтовую рассылку.
8. Иметь статистику что исправлено, а что нет. По бранчам как пример.

Я знаю сколько на разработку этого надо времени, только не знаю кто
заплатит за этот банкет. :)

-- 
Igor Zubkov
http://hi.im/ice