Cast Pinkbyte

Вопрос: команда безопасности Gentoo выкатывает пропатченные пакеты в дерево, или же только оповещает о том, какие версии безопасны, а какие - нет?

И ни то, и ни другое:

# eix-sync
 * Running emerge --sync
[...]

# eix -ce firefox
[I] www-client/firefox (38.3.0@10/13/2015): Firefox Web Browser

# glsa-check -t affected
This system is not affected by any of the listed GLSAs

https://www.mozilla.org/en-US/security/known-vulnerabilities/firefox-esr/#fir...

Такие дела.

Это тебе не поделка каких-нибудь фанбоев, а оттестированные коммиты монстров.

Я член gentoo security, то что ты видишь в glsa относится к дереву, небезопасные версии пакетов удаляются, оставляем только безопасные.

</thread>

Кукарекать то и я умею, лучше бы проверил то, что исправленной версии пакета в дереве еще нет.

исправленной версии пакета в дереве еще нет

выдаёт это за что-то хорошее

Ну в процессе же.

https://bugs.gentoo.org/show_bug.cgi?id=564818

Я член gentoo security
Кукарекать то и я умею

Это я уже понял.

лучше бы проверил то, что исправленной версии пакета в дереве еще нет

И то, что вы слоупоки, да еще и с бюрократией — тоже.

С момента анонса Firefox 42 и 38.4 ESR прошел 1 день и 6 часов.

Версию бампанули два часа назад.

Пользователи stable получили багфиксы? Нет.

Пользователи получили достоверную информацию при помощи GLSA? Нет.

Пользователи, синхронизирующие дерево при помощи emerge-webrsync с GPG-верификацией получат новые ебилды и GLSA metadata в тот же день? Нет.

О каком security тут идет речь?

А не насрать ли? Ведь если ты одминишь мегасервак, то он явно не под гентой, а под какой-нибудь дебьяношапкой десятилетней давности…

Что за бред? Как может пресловутый какир через моего огнелиса 38.3.0 получить доступ к моей системе? Идиотизм же!

201405-07: X.Org X Server: Multiple vulnerabilities
201507-20: PostgreSQL: Multiple vulnerabilities

Поздравляю тебя, Шарик, ты балбес.

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

И вообще, зачем вы, люди, верите в вирусы и руткиты?

<sarcasm>
Не всех война убила.
</sarcasm>

У этого треда пять подписантов, ты не мог бы свалить нахрен в толксы со своим бесполезным флудом?

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

emerge-webrsync, вследствие своих вполне ожидаемых особенностей, не будет поставлять актуальную информацию. Почему - и так ясно.

Что же касается 1 дня и 6 часов --- вроде бы, не так уж и долго. Хотя, Debian опередил часов на 14.

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

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

GLSA выпускается как только пакет стабилизирован на всех поддерживаемых архитектурах, а уязвимые версии удалены из главного дерева portage. Подробности процесса обработки уязвимостей можно прочесть в gentoo wiki, искать по Vulnerability treatment policy

А кто то скачивает портаж чаще чем раз в день?

Да. GLSA - это средство уведомления о том, что уязвимость закрыта в пакете на stable ветках всех поддерживаемых архитектурах. Само обновление выйдет раньше чем GLSA.

Вывод - пользователям сидящим на unstable и регулярно обновляющимся оно не нужно. Пользователям stable - нужно. Особенно если они предпочитают обновляться частями с упором на security-апдейты сначала(например на серверах)

Gentoo Linux Slowpoke Advisories

Само обновление выйдет раньше чем GLSA.

В чем тогда смысл GLSA, если оно приходит через неделю после официального анонса от вендора, когда всех уже успели поломать?

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

Ha ha ha, oh wow.

Состояние экосистемы Gentoo (комментарий)

emerge-webrsync, вследствие своих вполне ожидаемых особенностей, не будет поставлять актуальную информацию. Почему - и так ясно.

Что мешает паковать и подписывать архивы в автоматическом режиме не раз в день, а каждые шесть часов? Mirrors gonna mirror.

Отсутствие необходимости

Отсутствие необходимости

Это предложение как нельзя лучше характеризует феномен безопасности Gentoo.

Ну и вдобавок процитирую комментарий типичной целевой аудитории:

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

Ты блин нашёл, кого цитировать.

Это предложение как нельзя лучше характеризует феномен безопасности Gentoo.

emerge --sync

Это предложение как нельзя лучше характеризует феномен безопасности Gentoo.

emerge --sync

Gentoo и небезопасный emerge --sync

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

Нет. О том почему читай ниже.

Какие состояния проходит некий «дырявый» ebuild в вакууме?

• 0) Обнаружение самого факты наличия уязвимости
• 1) Факт наличия «дыры» регистрируется в cve либо в багзилле «дырявого» пакета либо в багзилле некоего дистрибутива
• 2) Факт наличия «дыры» регистрируется в багзилле gentoo
• 3) «Дыра» закрывается
• 4) Исправленный ebuild попадает в дерево
• 5) Для тех кто в танке выходит GLSA

И главное здесь заключается в том, что между каждыми из двух соседних пунктов проходит время... В реальности это уйма времени! В условиях когда на то чтобы воспользоваться уже выявленной кем-либо в пунктах 0 или 1 или 2 и незакрытой уязвимостью потребуются даже не часы или минуты время проходящее от пункта 0 до пунктов 4, 5 это непозволительная роскошь.

На выяснение того, сколько времени, иной раз, gentoo тратит на «дорогу» от пункта 2 до пунктов 3, 4, 5 я оставляю тем любознательным ЛОРовцам которые знаю где у gentoo багзилла.

Всем чмоки в этам чате!

Что-то как-то это депрессивно выглядит.

Тут обвиняют гентовское исправление дыр в неторопливости. Это обусловлено чем-то конкретным, или это просто совпадение случайных факторов каждый раз?

Что-то как-то это депрессивно объективно и очевидно выглядит.

А негативную эмоциональную окраску этим элементарным, очевидным фактам придали вы сами.

Это обусловлено чем-то конкретным, или это просто совпадение случайных факторов каждый раз?

Zlogene, Pinkbyte ?

А меня интересует почему не существует некой предварительной GLSA появляющейся непосредственно сразу по п. 2 т.е. по факту создания бага в багзилле gentoo и предостерегающей о существующей проблеме. На мой взгляд таким нехитрым способом аппстрим gentoo получит большую активность заинтерисованных пользователей. Т.е. больше логов/патчей и всем станет лучше.

по факту создания бага в багзилле gentoo

А у вас там есть уютненький stop reopening на сообщения о тормозах portage?

А у вас там есть уютненький stop reopening?)

Это не ко мне вопросы.

почему не существует некой предварительной GLSA появляющейся непосредственно сразу по п. 2 т.е. по факту создания бага в багзилле gentoo и предостерегающей о существующей проблеме.

Потому что GLSA делаются руками и это процесс небыстрый. И если мы бывает не успеваем делать обычные, то добавить еще столько же работы - быстрее оно не станет.

А так подобное уже предусмотрено в политике в качестве опциональной фичи. Например мы выпускаем GLSA если пакет содержит уязвимость и находится в состоянии удаления из дерева portage(masked for removal).

Ты описал путь регистрации обычной уязвимости о которых мы узнаем из открытых источников. А еще есть уязвимости, о которых мы узнаем из закрытых - в этом случае политика другая и фиксы выходят уже аккурат к CRD(Coordinated release date)

Это обусловлено чем-то конкретным

Очевидно же: бюрократия, желание поиграть в иерархическую структуру с эффективным тимворком™. Ebuild is ready, arch testers, go!

Вот пример как надо делать: http://article.gmane.org/gmane.os.openbsd.ports.cvs/98044

Исправлено 1 день и 6 часов назад. TESTED BY SEVERAL, КАРЛ!

В то время как т.н. «arch testers» в Gentoo еще даже не вдуплили, что же собственно происходит.

Объективным и очевидным это является, а выглядит именно депрессивно.

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

О какой вообще «работе» речь? Я вообще о том, что-бы при присваивании некоему открытому багу в багзилле генты метки к примеру «потенциально опасен для безопасности» далее скриптом, без всякого участия живых людей создавался бы документ с кратким описание, ссылкой на баг, ebuild и его версию со страшным заголовком «Не переживай раньше времени но обрати своё внимание ибо потенциальная проблема безопасности.» и любые заинтересованные в том юзеры получали бы его так же легко как и GLSA.

А дальше по выпуску GLSA закрывающей проблему документ из пула «потенциальных GLSA» удалялся бы.

Объективным и очевидным это является, а выглядит именно депрессивно.

Не путай объективное и личное восприятие.

Pinkbyte таки не выдержал и стабилизировал www-client/firefox на x86 и amd64, за что ему респект :)

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

О какой вообще «работе» речь?

https://wiki.gentoo.org/wiki/Project:Security/GLSAMaker_Guide

Там кратенькое описание, весь геморрой виден только членам Security team, ну и падаванам

Учитывая что arch team liasson на amd64 - целых 2 человека, а поток пакетов на стабилизацию не иссякает никогда - дружно делаем выводы

бюрократия, желание поиграть в иерархическую структуру с эффективным тимворком

Ответ гораздо проще - недобор.

В то время как т.н. «arch testers» в Gentoo еще даже не вдуплили, что же собственно происходит.

arch tester-ов(то есть пользователей, которые тестят и репортят что всё хорошо) в генте на amd64 сейчас НЕТ!

Тимлид команды amd64 arch tester - разработчик Gentoo.
amd64 arch team включает в себя 8 человек, но каждый в этой команде - не человек-оркестр, специфики работы всех пакетов знать нельзя.

Одна из причин почему я ушел из amd64 arch team - очень много времени жрёт стабилизация. Причём - не процессорного(хотя и его бывает с стабилизацией libreoffice-а нехватает).

Ответ гораздо проще - недобор.

Казалось бы, в условиях недобора следовало бы максимально упростить участие в проекте, а также сам процесс тестирования, а не городить бюрократию, будто бы на позицию AMD64 arch tester'a претендует 500 человек одновременно.

У Gentoo вообще есть список приоритетных целей (goals)? Что важнее: чтобы у пользователей собирался их любимый Firefox, или чтобы они не сидели с дырявым Firefox-ом в сети?

Одна из причин почему я ушел из amd64 arch team - очень много времени жрёт стабилизация. Причём - не процессорного

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

https://wiki.gentoo.org/wiki/Project:Security/Padawan_Process

Once you have achieved the status of developer in the previous step, there's nothing left to do security-wise.

Феерично.

Объясни.

в условиях недобора следовало бы максимально упростить участие в проекте, а также сам процесс тестирования, а не городить бюрократию, будто бы на позицию AMD64 arch tester'a претендует 500 человек одновременно.

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

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

Они думают что у нас недобор. Сюрприз! И все попытки упростить процесс приёма вели пока только к одному - отвратному качеству ебилдов у новых разработчиков. С которыми потом еще по полгода приходится няньчиться

Объясни.

https://ru.wiktionary.org/wiki/почивать_на_лаврах

Последний этап в карьере security-only-разработчика в Gentoo - получить коммит-доступ в главное дерево portage.

У нас сейчас даже есть один разработчик в Gentoo Security без commit-доступа в дерево portage. Он занимается чисто координацией GLSA и имеет голос при утверждении кандидатур падаванов.

Но ни сама стабилизация, ни security bump ебилдов ему не доступны. Потому что quiz-ы он не сдавал. Собирался, но забросил.