Политика Gentoo в отношении обновлений безопасности

Вообще меня умиляют люди(это я не про ТС, а про остальных отписавшихся в треде), которые совершенно не в теме происходящих внутри процессов(и почему они происходят именно так,а не иначе), но которые упорно пытаются рассказывать своё, уникальное, идеальное видение как сделать чтобы дистрибутив был зашибись.

Хотя чего скрывать - сам был такой. Только после того как посмотрел на ситуацию изнутри - понял, что половина моих идей «как сделать зашибись» не имеет ничего общего с реальностью и проблемы надо решать совсем другие.

А jflex когда-нибудь починят? А то оно без java_cup.runtime не собирается, а javacup почему-то должен устанавливаться позже, чем jflex.

Если что, версия jflex - 1.6.1

У островных каргокультистов тоже свои процессы, и уникальное видение белых людей их не интересует.

Ок, то есть ты считаешь что если я приду, например, к художнику и начну ему рассказывать как правильно рисовать(опустим тот факт, что это творческий процесс, всё же есть какие-то основы), при том что я нихрена в этом не смыслю, рисовать не умею(ну ты понел) - это будет норма, да?

Не, ну а чо это он - его что, мнение белых людей не интересует?! :-)

У теологов тоже есть специальность, там тоже можно много всего изучать, проводить семинары, и посмеиваться на неграмотными в её вопросах оппонентами. Что не отменяет того факта, что теология просто кулстори не несущая никакого профита в реальности.

Багрепорт есть? А то что из меня, что из zlogene я подозреваю джависты так себе. Но можно попинать чувак из Gentoo Java team

И? Ты считаешь что Gentoo «не несет никакого профита в реальности»? Рад за тебя. Дальше что?

Gentoo несёт, каргокультизм в её рядах — нет. Эти вещи существуют паралленьно и вторая мешает первой.

Окей, расскажи что по твоему мнению надо упростить в тестировании пакетов. Не проверять на работоспособность? Проверять только одну комбинацию USE-флагов, а на остальные насрать? А может вообще не проверять, ну его нафиг, хреначим stable - и ладно!

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

Кстати, ты так и не ответил на вопрос о целях проекта Gentoo.

Нет. Нужно соблюдать хотя бы минимальный уровень качества. Дать доступ к главном дереву анонимусам на R/W - это не есть качество. А вот упрощения жизни рядовым контрибьюторам - таки да. Зеркало на гитхабе не просто так появилось.

Кстати, ты так и не ответил на вопрос о целях проекта Gentoo.

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

Технические цели - они у каждого подпроекта свои, в рамках основной.

Base system обеспечивает функционирование базовой системы, toolchain - соответственно утилит сборки. Языковые проекты(Perl, Python и т.д.) - соответственно поддержку определенных языков.

Gentoo Alt - возможность использования Gentoo на других ядрах или платформах(FreeBSD, Cygwin, MacOS X, FreeMint).

Описывать каждый проект мне в данный момент лениво - на wiki всё есть.

Эмм... я попытаюсь объяснить или предложить с точки зрения юзера. При всём моем уважении к гентудевам.

Некоторые пользователи могут относиться весьма щепетильно к вопросу наличия и отсутствия уязвимостей на их системе. И было бы неплохо получать информацию сразу об известных разрабам Gentoo уязвимостям, даже если ещё нет исправления и только открыт баг-репорт. Речь идет об уязвимостях, которые получены из открытых источников.

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

Пока в генте такого нет - приходится ещё и мониторить, а когда прилетят баги на баг-трекер. Это неудобно (опять же, с точки зрения юзера). Куда удобнее было бы запустить в кроне проверялку, которая чекает и на email шлет, есть ли открытые баг-репорты (или известные уязвимости) в установленных ебилдах. Как именно предварительно оформлять известные уязвимости - это уже технические детали.

Конечно, прекрасно, что у вас есть уже устоявшиеся правила. Но, может, стоит рассмотреть их возможную модификацию?

Вот, пошел конструктивный диалог, без наездов.

Некоторые пользователи могут относиться весьма щепетильно к вопросу наличия и отсутствия уязвимостей на их системе

Это разумно.

И было бы неплохо получать информацию сразу об известных разрабам Gentoo уязвимостям, даже если ещё нет исправления и только открыт баг-репорт. Речь идет об уязвимостях, которые получены из открытых источников.

Из самого простого - можно посмотреть открытые баги на нашей багзилле. В поиске выбрать в качестве Product - Gentoo Security, компонент - Vulnerabilities. Update: сообщение не читай, сразу отвечай :-)

Пока в генте такого нет - приходится ещё и мониторить, а когда прилетят баги на баг-трекер. Это неудобно (опять же, с точки зрения юзера). Куда удобнее было бы запустить в кроне проверялку, которая чекает и на email шлет, есть ли открытые баг-репорты (или известные уязвимости) в установленных ебилдах.

Согласен, такая утилита была бы удобной. К сожалению лично я абсолютно не представляю как это реализовать технически. Я имею ввиду полноценно - набросать на pybugz или cbugzilla консольный поисковик по вышеописанным критериям да погрепать по установленным ебилдам - это еще не все что нужно...

Конечно, прекрасно, что у вас есть уже устоявшиеся правила. Но, может, стоит рассмотреть их возможную модификацию?

Безусловно. Но я лично не привык писать в мэйллист когда у меня в голове нет хотя бы примерного плана как это реализовать. За голые идеи у нас среди разработчиков не ругают конечно, но как правило высказавший идею сам вызывается её реализовывать. А как я уже сказал - я хз.

Другое дело если это напишет пользователь. Дистрибутив-то пишется в первую очередь для пользователей. И требовать с них сразу готовую реализацию никто не будет. А значит вполне найдутся люди, которые смогут удовлетворить спрос, если таковой будет.

Куда удобнее было бы запустить в кроне проверялку, которая чекает и на email шлет, есть ли открытые баг-репорты (или известные уязвимости) в установленных ебилдах.

https://lists.mozilla.org/listinfo/announce
https://lists.mindrot.org/mailman/listinfo/openssh-unix-announce
http://mailman.nginx.org/mailman/listinfo/nginx-announce

Ну и так далее.

А если у тебя установлено столько ебилдов, что невозможно в разумное время подписаться на все рассылки — тогда you'll get rekt anyway.

К сожалению лично я абсолютно не представляю как это реализовать технически. Я имею ввиду полноценно - набросать на pybugz или cbugzilla консольный поисковик по вышеописанным критериям да погрепать по установленным ебилдам - это еще не все что нужно...

А что ещё нужно? Если бы мне поставили такое ТЗ, то первое, что приходит в голову:

1. Создание бага на багзилле.
2. В атрибутах указание, что это security issue (вроде, уже указывают?)
3. Отталкиваясь от того, что в названии бага сначала идет ATOM (вида foo/bar-3.2 или <=foo/bar-4.3:4), делаем запрос всех open security issue, и вытягиваем ATOM. Возможно, понадобится доработать схему именований багов, чтобы можно было точно выцепить уязвимые версии (как-то можно в атрибутах бага задавать дополнительные строки в багзилле? туда можно записывать exclude, сами atom'ы конкретной версии или с маской).
4. Клиентская утилита должна делать запрос к багзилле и получать список открытых issue с подверженными уязвимостям версиями. И сравнивать с текущими установленными ебилдами.
5. Поскольку запросы к багзилле будут сильно нагружать сервер, то можно сделать server-side скрипт, который периодично делает запрос (например, раз в 10 минут), и генерирует статический файл, который уже отдается обычным веб-сервером. А клиентская софтина скачивает уже кешированный результат.

Багрепорт сделаю сегодня вечером.

Куча java-софта из-за этого не ставится.

что в названии бага сначала идет ATOM (вида foo/bar-3.2 или <=foo/bar-4.3:4),

Или вида <=foo/{bar,baz,lol}-version или даже <=foo/bar{,-baz,-lol}-version

Тут глоббинг башевый нужно применять явно и то не факт что спасёт

А вот пункт 5 мне нравится

В таком виде ты готов закинуть в mail-рассылку? Боюсь, что у меня на английском получится коряво.

А тем временем Sven Vermeulen похоже сделал то что не просто касается нашего разговора... А было бы даже полезнее GLSA

Нету в дереве.

Нету в дереве.

Ты только подумай какая печаль!

С такой логикой и gentoo не нужна, можно накрасноглазить lfs.

С такой логикой и gentoo не нужна, можно накрасноглазить lfs.

anonymous-ы неосиливающие ебюлды не нужны.

неосиливающие ебюлды

proofs