[devel] Vulnerability policy

[devel] Vulnerability policy

[lineprinter]

Назрела необходимость в https://www.altlinux.org/Vulnerability_Policy
для security-tracker'а, которого еще нет. Предлагаю обсудить.

Re: [devel] Vulnerability policy

[Anton Farygin]

21.02.2017 20:29, lineprinter пишет:
> Назрела необходимость в https://www.altlinux.org/Vulnerability_Policy
> для security-tracker'а, которого еще нет. Предлагаю обсудить.

Странно общаться в devel с принтером, пусть он даже line и очень быстр.
Предлагаю начать обсуждение с этого ;)

И да, т.к. CVE бывает исправлено много или очень много, то как мне 
кажется, достаточно просто указания CVE-xxxx-xxxxx без скобочек. А для 
начала неплохо было бы посмотреть что там обычно пишут на эту тему 
ментейнеры в ченжлогах, и как это выгребается в 
https://packages.altlinux.org/en/Sisyphus/security

Re: [devel] Vulnerability policy

[Michael Shigorin]

On Tue, Feb 21, 2017 at 08:49:27PM +0300, Anton Farygin wrote:
> И да, т.к. CVE бывает исправлено много или очень много, то как мне 
> кажется, достаточно просто указания CVE-xxxx-xxxxx без скобочек.

Соглашусь:
http://packages.altlinux.org/ru/Sisyphus/srpms/adobe-flash-player/changelog

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] Vulnerability policy

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 964 bytes --]

On Tue, Feb 21, 2017 at 09:33:12PM +0300, Michael Shigorin wrote:
> On Tue, Feb 21, 2017 at 08:49:27PM +0300, Anton Farygin wrote:
> > И да, т.к. CVE бывает исправлено много или очень много, то как мне 
> > кажется, достаточно просто указания CVE-xxxx-xxxxx без скобочек.
> 
> Соглашусь:
> http://packages.altlinux.org/ru/Sisyphus/srpms/adobe-flash-player/changelog

Я бы предпочёл, чтобы вместо

- new version
- security fixes:
  CVE-2016-7857, CVE-2016-7858, CVE-2016-7859, CVE-2016-7860,
  CVE-2016-7861, CVE-2016-7862, CVE-2016-7863, CVE-2016-7864,
  CVE-2016-7865

в %changelog пакета adobe-flash-player было написано

- new version (fixes: CVE-2016-7857, CVE-2016-7858, CVE-2016-7859,
  CVE-2016-7860, CVE-2016-7861, CVE-2016-7862, CVE-2016-7863,
  CVE-2016-7864, CVE-2016-7865)

Но если кому-то существенно удобнее записывать это как-то иначе и без
скобочек, то, наверное, это можно формализовать и включить в правила.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] Vulnerability policy

[Anton Farygin]

21.02.2017 21:44, Dmitry V. Levin пишет:
> Но если кому-то существенно удобнее записывать это как-то иначе и без
> скобочек, то, наверное, это можно формализовать и включить в правила.

Мне в последнее время нравится такая трактовка, предпочёл бы её, когда 
есть время всё это описывать:

- Fixed:
+ CVE-2017-5375: Excessive JIT code allocation allows bypass of ASLR and DEP
+ CVE-2017-5376: Use-after-free in XSL
+ CVE-2017-5377: Memory corruption with transforms to create gradients 
in Skia
+ CVE-2017-5378: Pointer and frame data leakage of Javascript objects
+ CVE-2017-5379: Use-after-free in Web Animations
+ CVE-2017-5380: Potential use-after-free during DOM manipulations
+ CVE-2017-5390: Insecure communication methods in Developer Tools JSON 
viewer
+ CVE-2017-5389: WebExtensions can install additional add-ons via 
modified host requests
+ CVE-2017-5396: Use-after-free with Media Decoder
+ CVE-2017-5381: Certificate Viewer exporting can be used to navigate 
and save to arbitrary filesystem locations
+ CVE-2017-5382: Feed preview can expose privileged content errors and 
exceptions
+ CVE-2017-5383: Location bar spoofing with unicode characters
+ CVE-2017-5384: Information disclosure via Proxy Auto-Config (PAC)
+ CVE-2017-5385: Data sent in multipart channels ignores referrer-policy 
response headers
+ CVE-2017-5386: WebExtensions can use data: protocol to affect other 
extensions
+ CVE-2017-5394: Android location bar spoofing using fullscreen and 
JavaScript events
+ CVE-2017-5391: Content about: pages can load privileged about: pages
+ CVE-2017-5392: Weak references using multiple threads on weak proxy 
objects lead to unsafe memory usage
+ CVE-2017-5393: Remove addons.mozilla.org CDN from whitelist for 
mozAddonManager
+ CVE-2017-5395: Android location bar spoofing during scrolling
+ CVE-2017-5387: Disclosure of local file existence through TRACK tag 
error messages
+ CVE-2017-5388: WebRTC can be used to generate a large amount of UDP 
traffic for DDOS attacks
+ CVE-2017-5374: Memory safety bugs fixed in Firefox 51
+ CVE-2017-5373: Memory safety bugs fixed in Firefox 51 and Firefox ESR 45.7

Re: [devel] Vulnerability policy

[Michael Shigorin]

On Tue, Feb 21, 2017 at 10:02:57PM +0300, Anton Farygin wrote:
> Мне в последнее время нравится такая трактовка, предпочёл бы
> её, когда есть время всё это описывать:
> 
> - Fixed:
> + CVE-2017-5375: Excessive JIT code allocation allows bypass of ASLR and DEP
> + CVE-2017-5376: Use-after-free in XSL

Кстати, и впрямь ведь есть не только CVE, а трансляцию между
различными агрегаторами явно лучше поручить коду, не людям.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] Vulnerability policy

[Alexey Gladkov]

On Tue, Feb 21, 2017 at 10:02:57PM +0300, Anton Farygin wrote:
> 21.02.2017 21:44, Dmitry V. Levin пишет:
> > Но если кому-то существенно удобнее записывать это как-то иначе и без
> > скобочек, то, наверное, это можно формализовать и включить в правила.
> 
> Мне в последнее время нравится такая трактовка, предпочёл бы её, когда 
> есть время всё это описывать:

elinks -dump-width 2000 "https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/" |
	grep '\]#CVE-' |
	sed -e 's,^.*#,  + ,'

:)

> - Fixed:
> + CVE-2017-5375: Excessive JIT code allocation allows bypass of ASLR and DEP
> + CVE-2017-5376: Use-after-free in XSL
> + CVE-2017-5377: Memory corruption with transforms to create gradients 
> in Skia
> + CVE-2017-5378: Pointer and frame data leakage of Javascript objects
> + CVE-2017-5379: Use-after-free in Web Animations
> + CVE-2017-5380: Potential use-after-free during DOM manipulations
> + CVE-2017-5390: Insecure communication methods in Developer Tools JSON 
> viewer
> + CVE-2017-5389: WebExtensions can install additional add-ons via 
> modified host requests
> + CVE-2017-5396: Use-after-free with Media Decoder
> + CVE-2017-5381: Certificate Viewer exporting can be used to navigate 
> and save to arbitrary filesystem locations
> + CVE-2017-5382: Feed preview can expose privileged content errors and 
> exceptions
> + CVE-2017-5383: Location bar spoofing with unicode characters
> + CVE-2017-5384: Information disclosure via Proxy Auto-Config (PAC)
> + CVE-2017-5385: Data sent in multipart channels ignores referrer-policy 
> response headers
> + CVE-2017-5386: WebExtensions can use data: protocol to affect other 
> extensions
> + CVE-2017-5394: Android location bar spoofing using fullscreen and 
> JavaScript events
> + CVE-2017-5391: Content about: pages can load privileged about: pages
> + CVE-2017-5392: Weak references using multiple threads on weak proxy 
> objects lead to unsafe memory usage
> + CVE-2017-5393: Remove addons.mozilla.org CDN from whitelist for 
> mozAddonManager
> + CVE-2017-5395: Android location bar spoofing during scrolling
> + CVE-2017-5387: Disclosure of local file existence through TRACK tag 
> error messages
> + CVE-2017-5388: WebRTC can be used to generate a large amount of UDP 
> traffic for DDOS attacks
> + CVE-2017-5374: Memory safety bugs fixed in Firefox 51
> + CVE-2017-5373: Memory safety bugs fixed in Firefox 51 and Firefox ESR 45.7
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

-- 
Rgrds, legion

Re: [devel] Vulnerability policy

[Sergey V Turchin]

On Tuesday, 21 February 2017 21:44:33 MSK Dmitry V wrote:
> On Tue, Feb 21, 2017 at 09:33:12PM +0300, Michael Shigorin wrote:
> > On Tue, Feb 21, 2017 at 08:49:27PM +0300, Anton Farygin wrote:
> > > И да, т.к. CVE бывает исправлено много или очень много, то как мне
> > > кажется, достаточно просто указания CVE-xxxx-xxxxx без скобочек.
> > 
> > Соглашусь:
> > http://packages.altlinux.org/ru/Sisyphus/srpms/adobe-flash-player/changelo
> > g
> 
> Я бы предпочёл, чтобы вместо
> 
> - new version
> - security fixes:
>   CVE-2016-7857, CVE-2016-7858, CVE-2016-7859, CVE-2016-7860,
>   CVE-2016-7861, CVE-2016-7862, CVE-2016-7863, CVE-2016-7864,
>   CVE-2016-7865
> 
> в %changelog пакета adobe-flash-player было написано
Конкретно в этом случае мне абсолютно без разницы, что писать по обе стороны 
такого перечисления CVE.

[...]

-- 
Regards, Sergey.

Re: [devel] Vulnerability policy

[Michael Shigorin]

On Wed, Feb 22, 2017 at 10:31:06AM +0300, Sergey V Turchin wrote:
> > > > И да, т.к. CVE бывает исправлено много или очень много, то как мне
> > > > кажется, достаточно просто указания CVE-xxxx-xxxxx без скобочек.
> > > Соглашусь:
> > > http://packages.altlinux.org/ru/Sisyphus/srpms/adobe-flash-player/changelog
> > Я бы предпочёл, чтобы вместо
> > 
> > - new version
> > - security fixes:
> >   CVE-2016-7857, CVE-2016-7858, CVE-2016-7859, CVE-2016-7860,
> >   CVE-2016-7861, CVE-2016-7862, CVE-2016-7863, CVE-2016-7864,
> >   CVE-2016-7865
> > 
> > в %changelog пакета adobe-flash-player было написано
> Конкретно в этом случае мне абсолютно без разницы, что писать
> по обе стороны такого перечисления CVE.

Это, кстати, ещё и про то, подхватится ли уже существующая
информация из предыдущих сборок; я бы, если и хотел "иначе",
постарался разбирать и то, как уже есть.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] Vulnerability policy

[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?

-- 
~dd

Re: [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

Re: [devel] Vulnerability policy

[Andrew Clark]

22 февраля 2017 г., 13:07 пользователь Igor Zubkov
<igor.zubkov@gmail.com> написал:

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

"Денег сейчас нет... Вы держитесь здесь, Вам всего доброго, хорошего настроения
и здоровья" [c] жалкий

-- 
Talk is cheap, show me the code (c) Linus Torvalds

Re: [devel] Vulnerability policy

[lineprinter]

2017-02-21 20:49 GMT+03:00 Anton Farygin <rider@altlinux.com>:
> И да, т.к. CVE бывает исправлено много или очень много, то как мне кажется,
> достаточно просто указания CVE-xxxx-xxxxx без скобочек.

Недостаточно, потому что идентификатор уязвимости иногда указывается
не только в контексте её исправления.

Re: [devel] Vulnerability policy

[Anton Farygin]

28.02.2017 20:04, lineprinter пишет:
> 2017-02-21 20:49 GMT+03:00 Anton Farygin <rider@altlinux.com>:
>> И да, т.к. CVE бывает исправлено много или очень много, то как мне кажется,
>> достаточно просто указания CVE-xxxx-xxxxx без скобочек.
>
> Недостаточно, потому что идентификатор уязвимости иногда указывается
> не только в контексте её исправления.

Есть такие примеры ?

Re: [devel] Vulnerability policy

[lineprinter]

По результатам обсуждения страница
https://www.altlinux.org/Vulnerability_Policy была обновлена, желающим
предлагаю прокомментировать.

2017-02-21 20:29 GMT+03:00 lineprinter <lineprinter@altlinux.org>:
> Назрела необходимость в https://www.altlinux.org/Vulnerability_Policy
> для security-tracker'а, которого еще нет. Предлагаю обсудить.

Re: [devel] Vulnerability policy

[Alexey Tourbin]

2017-02-28 20:06 GMT+03:00 lineprinter <lineprinter@altlinux.org>:
> По результатам обсуждения страница
> https://www.altlinux.org/Vulnerability_Policy была обновлена, желающим
> предлагаю прокомментировать.

Пожалуйста. Во-первых, %changelog есть не место для дискуссий, то есть
озабоченность одних людей не должна передаваться другим. Сборка новой
версии пакета для мейнтейнера - достаточное условие, чтобы забыть обо
всяких уязвимостях в прежних версиях пакета.

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

Re: [devel] Vulnerability policy

[Евгений Терешков]

Alexey Tourbin пишет:

> Во-вторых, механика обновления уязвимых пакетов на нижнем уровне никак
> не проработана. Процесс может болтаться со старой разделяемой
> библиотекой, которая давно уже стерта в фс, до пришествия Христа.
> Проблема решается только полной перезагрузкой.

Не совсем так. См. пакет needrestart. Ничего не мешает автоматически
перезапускать затрагиваемые сервисы, почти что любые, было бы желание.

-- 
С уважением, Терешков Евгений.
Jabber ID: evg@altlinux.org, evg_krsk@jabber.ru

Re: [devel] Vulnerability policy

[Alexey Tourbin]

2017-02-28 20:51 GMT+03:00 Евгений Терешков <evg-krsk@yandex.ru>:
> Alexey Tourbin пишет:
>
>> Во-вторых, механика обновления уязвимых пакетов на нижнем уровне никак
>> не проработана. Процесс может болтаться со старой разделяемой
>> библиотекой, которая давно уже стерта в фс, до пришествия Христа.
>> Проблема решается только полной перезагрузкой.
>
> Не совсем так. См. пакет needrestart. Ничего не мешает автоматически
> перезапускать затрагиваемые сервисы, почти что любые, было бы желание.

При обновлении системных библиотек, насколько я знаю, сервисы в связи
с этим штатно никак перезапустить нельзя. Нету такого штатного
механизма, чтобы вследствие rename() в /lib64 какой-то сервис в
добровольно-принудительном порядке сделал exec("/proc/self/exe").

Это приводит меня к мысли, что подписчик или подписчица, которая
поставила вопросы в начальном письме, она их не обдумала. Потому что
никакого нормального исхода из этих вопросов нету. :-(

Re: [devel] needrestart (was: Vulnerability policy)

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1374 bytes --]

Меняю тему на needrestart, поскольку Vulnerability policy тут уже
не при чём.

On Tue, Feb 28, 2017 at 09:12:04PM +0300, Alexey Tourbin wrote:
> 2017-02-28 20:51 GMT+03:00 Евгений Терешков <evg-krsk@yandex.ru>:
> > Alexey Tourbin пишет:
> >
> >> Во-вторых, механика обновления уязвимых пакетов на нижнем уровне никак
> >> не проработана. Процесс может болтаться со старой разделяемой
> >> библиотекой, которая давно уже стерта в фс, до пришествия Христа.
> >> Проблема решается только полной перезагрузкой.
> >
> > Не совсем так. См. пакет needrestart. Ничего не мешает автоматически
> > перезапускать затрагиваемые сервисы, почти что любые, было бы желание.
> 
> При обновлении системных библиотек, насколько я знаю, сервисы в связи
> с этим штатно никак перезапустить нельзя. Нету такого штатного
> механизма, чтобы вследствие rename() в /lib64 какой-то сервис в
> добровольно-принудительном порядке сделал exec("/proc/self/exe").

Цитата из https://github.com/liske/needrestart:
"needrestart checks which daemons need to be restarted after library upgrades"

Вполне традиционный подход, он ещё и до systemd работал, когда вполне
надёжного способа определить, какому сервису принадлежит данный pid,
ещё не было.

Если файл библиотеки переименовался и не удалился в результате обновления,
то это результат какого-то жульничества.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] Vulnerability policy

[Alexey Tourbin]

2017-02-28 20:06 GMT+03:00 lineprinter <lineprinter@altlinux.org>:
> По результатам обсуждения страница
> https://www.altlinux.org/Vulnerability_Policy была обновлена, желающим
> предлагаю прокомментировать.

Полагаться на %changelog - плохая идея. В моей практике знаете какой
был случай? Один пациент прислал мне пакет postgesql.src.rpm с
исправлением уязвимости, чтобы я собрал его в updates. (Было это в
2003 году, тогда еще не было бранчей, а были updates для
дистрибутивов.)  И вот я из любопытства просматриваю этот пакет,
строчка Patch: там есть, а соответствующей строчки %patch - нету. Я
пациенту пишу: патч не прикладывается. Он: то есть как это не
прикладывается? То есть совсем не прикладывается. Языковая
двусмысленность такая немного смешная.

Полагаться на исправленную версию - несколько лучше. Поскольку
облажаться пациенту в этом случае сложнее. Проблема только в том, что
опережающая версия иногда используется для сборки пререлизов (такие
сборки часто получают релиз alt0.1 и т.д.) Поэтому в плане версий
можно выделить три случая:

- версия > succ(v) - уязвимость исправлена (где v - уязвимая версия).
- версия = succ(v) - пограничный случай, смотрим на релиз alt0*.
- версия = v - скорее всего не исправлена, если нет упоминания в %changelog.

Но это только если бы версии последовательно нумеровались. Если,
например, уязвимы версии вплоть до 3.3, а в сизифе имеется
4.0-alt-0.1, то сказать что либо сложно. Кроме того, релизы alt0*
перегружены: они также используются для бекпортов в бранчи.

Вообще, если ставить дело на серьезную ногу, то вся это эвристика не
годится, а играют роль только два критерия: 1) текстовое совпадение в
коде (а именно, сделать rpm -bp и дальше смотреть, прикладывается ли
патч или наоборот patch -R); 2) воспроизводимость уязвимости. Нужно
уметь воспроизвести уязвимость в уязвимой версии и показать, что
уязвимость больше не воспроизводится в исправленной версии.  Это самое
тяжелое, и это конечно надо стараться как-то автоматизировать.  Я в
свое время несколько пакетов так исправил.

Потом мне это надоело до чертиков. Там еще было очень много
имитационной деятельности. То есть нужно было писать анонс:
"обнаружена уязвимость, потенциальный злоумышленник может вас задрать"
и там еще ссылки надо было вставлять на скачивание rpm-пакетов. Ну в
общем подражание Ред Хату при отсутствии редхатовских клиентов и
бюджетов - маразм в чистом виде.

Дались они вам эти уязвимости. Мой опыт показывает, что сколько их не
исправляй, они тут же новые вскакивают. Как говорил Иисус Христос,
сборка обновлений - это суета и томление духа.  Советую вам лучше
что-нибудь выпить. В Пятерочке сейчас продается Rauli Chardonnay 2015
за 300 с небольшим рублей. По-моему, ничего.

Re: [devel] Vulnerability policy

[Alexey Tourbin]

2017-02-28 20:06 GMT+03:00 lineprinter <lineprinter@altlinux.org>:
> По результатам обсуждения страница
> https://www.altlinux.org/Vulnerability_Policy была обновлена, желающим
> предлагаю прокомментировать.

Уважаемый мужчина или женщина! Вы удостоились ответа, который сейчас
обсуждается на фейсбуке людьми намного старше вас. Будет архистранно,
если вы не захотите что-нибудь ответить.

Re: [devel] Vulnerability policy

[Sergey Afonin]

On Friday 03 March 2017, Alexey Tourbin wrote:

> обсуждается на фейсбуке

Ничего личного, но я бы не пошёл. А, если что, как
это всё искать потом в фесбуковском мусоре ?

-- 
С уважением, Сергей Афонин.

Re: [devel] Vulnerability policy

[Alexey Tourbin]

2017-03-03 18:00 GMT+03:00 Sergey Afonin <asy@altlinux.ru>:
> On Friday 03 March 2017, Alexey Tourbin wrote:
>
>> обсуждается на фейсбуке
>
> Ничего личного, но я бы не пошёл. А, если что, как
> это всё искать потом в фесбуковском мусоре ?

You put more to in than there it is.
There is only a mild urge to the young lady to continue the discussion.

Re: [devel] Vulnerability policy

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 507 bytes --]

On Tue, Feb 28, 2017 at 08:06:06PM +0300, lineprinter wrote:
> По результатам обсуждения страница
> https://www.altlinux.org/Vulnerability_Policy была обновлена, желающим
> предлагаю прокомментировать.

Поскольку возражений не поступило, будем считать эти правила принятыми.

> 2017-02-21 20:29 GMT+03:00 lineprinter <lineprinter@altlinux.org>:
> > Назрела необходимость в https://www.altlinux.org/Vulnerability_Policy
> > для security-tracker'а, которого еще нет. Предлагаю обсудить.

-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]