В Gentoo больше не будет Hardened-сборок ядра Linux

Hardened Gentoo это не только PaX

Я, как скромный хомячок, ровно так и считаю

Я как бы тоже. Вот только как раз те люди, которые кричали «ваши патчи говно» и не брали в ядро, теперь возбухают и грозят (или уже) судиться. Под соусом «комунити» и gpl. Цирк-шапито.

Сам понял, что ляпнул?

Вот только как раз те люди, которые кричали «ваши патчи говно» и не брали в ядро, теперь возбухают и грозят (или уже) судиться.

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

Более того, я решительно привествую такое поведение. Такого типа проприетарщиков нужно бить их же оружием. И даже больше, товарищ RMS делает великое дело.

Откуда инфа, что это одни и те же люди?

Ну ок, ещё selinux, но очевидно, главное было ядро с PaX/grsec, selinux у красношапки лучше

Вообще это профиль целый, там нескучные gcc/glibc, например

В чём проблема форкнуть старые?

Поддерживать и развивать кто будет?

Увы, это не гипотеза, это инсайд-инфа :-(

все шишки - в адрес GrSecurity

В первый раз слышу про китайцев. Мне не понятно, почему GrSecurity не смогли на сайте большими буквами написать, что у них поддержка платная, либо обращайтесь к поставщику своего ядра (или производителю устройства с Linux). В результате и от халявщиков отбились бы и от нормальных мейнтейнеров (вроде Gentoo) получили бы реальную помощь с серьезной пользовательской базой (если в Gentoo Hardened обнаруживается ошибка, то мейнтейнеры Gentoo помогут ее локализовать и отфильтровать ложные сообщения).

А фанатики Redhat с пеной у рта доказывали, что systemd не закроют и тивоизационный капкан не захлопнется. Лучше несвободная Windows со свободным железом, чем свободный Linux с несвободным тивоизированным железом.

Что за несвязный бред я только что прочитал?

А что, к GrSecurity или RSBAC есть вагон готовых политик под десктоп?

GrSecurity использовал лет 20 назад, когда, кажется, только они предлагали защиту от выполнения стека. С RSBAC разбирался на Adamantix, так и не понял, как работает RBAC. SElinux пылася настроить, несколько раз, последний - когда мигрировал приложение с Debian на CentOS. Насколько я понял, SElinux написали для министерства обороны США и на практике только им он и полезен.

Потому что настраивается SElinux только для стандартных приложений, которые идут из репозитория RedHat и работают с более-менее стандартной конфигурации. Шаг вправо-влево или свое приложение - и настраивать SElinux запаришься (насколько я понял, сейчас есть специальная организация, которая собирает, обсуждает и одобряет набор политик). Так что нужен он на практике, разве что, на ЛОРе перед одноклассниками понтоваться, ну или свою зарплату оправдывать, если ты IT-безопасник и весь день только тем и занимаешься, что политики настраиваешь (и, таким образом, разработчиков жестко ограничиваешь, что может делать их приложение, а чего низачто ни в коем случае, потому что тогда SElinux не настроить). Кто пытался какой-нибудь Apache ограничить, в котором веб приложение работает, тот поймет, о чем я.

ACL там не сложный

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

А этим кто-то пользовался кроме «я у мамы оптимизатор локалхоста»?

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

Grsecurity содержит много хороших патчей, у них есть несколько патчей, которые в основном звучат так: «Эй, мы можем сломать совместимость, потому что мы хотим сделать некоторые вещи более безопасными. Неважно, все равно никто не хочет использовать конечный результат.»

А как патчи к GPL ядру могут быть закрытыми? В случае с драйверами можно понять рассуждения: всё-таки драйвер это вещь в себе, а не производная работа от ядра, хотя и тут потребовалось чёткое разрешение от Линуса. А grsecurity это явно производная работа.

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

Похоже на дырку в GPL. Обязательно надо судиться. Плохой прецедент.

В ядро берут не всё подряд. Это не даёт права нарушать лицензию.

А кто мешает писать ebuild для закрытых продуктов с ограничениями загрузки? Делаешь для него fetch restricted и пользователь сам должен скачать файл установки и запихнуть в distfiles. Так сделано, например, для java jre/jdk, intel mkl.

Вопрос не в ебюлде дурашка. Вопрос в поддержке. Раньше была официальная поддержка в gentoo. А теперь gentoo оффициально насрать откуда ты будешь брать патчи и кто будет разгребать и решать твои ошибки. Аппстрим ядра кстати тоже угадай куда тебя пошлет с твоми багами у твоего hardened ядра?

Там причина больше идеологическая чем техническая

Да нет, скорее техническая. Не зря же Торвальдс их туда-сюда по трафарету за говнокодинг и то, в каком виде патч представлен, разложил.

Ребзя зазвездилась короче. Надеюсь скоро о них все забудут.

Известно куда пошлёт - к автору патчей. Только не пошлёт, так как я сразу автору патча баг бы отправил, дурашка.

В чём проблема форкнуть старые?

У меня проблема форкнуть своё собственное, единолично напиленное, перевести с Java на C++, с WinAPI на QT, с DirectX на OpenGL, с asm'а на C, а ты тут упражняешься в остроумии.

Только не пошлёт, так как я сразу автору патча баг бы отправил, дурашка.

А автор патча тебя, дурашка, пошлет аргументируя тем, что «у него %%название_дистрибутива а что там нагородили в этих ваших гентах майнтрейниры своими левыми пятками ему не ведомо и разбиратся в этом тоже никакого желания нет ибо человек он занятой.» и будет прав.

Ляпота!

К слову, речь первоначально шла именно о возможности создания ebuild (в контексте утечки патчей), а официально оно поддерживается или нет речи не было.

А пошлёт или нет это ещё неизвестно, если баг, разумеется, нормально оформлен, а не в виде сообщения «у меня поломалося».

Шаг вправо-влево или свое приложение - и настраивать SElinux запаришься

Это несколько преувеличено, если сказать культурно.

Похоже на дырку в GPL. Обязательно надо судиться

Как раз таки очень чревато судиться - если выиграют grsec, то gpl можно выкинуть.

Ну и славно, зачем нужна неработающая лицензия. GPL выкинуть, вкинуть другую лицензию. Мне вообще не нравится идея того, что только клиенты могут требовать исходники, это очень странное ограничение. Может в 1980-х это имело смысл, когда интернета толком не было и исходники на компакт-дисках распространяли, сейчас надо просто в лицензии прописать — выложить в публичный доступ исходники и всё, баста.

hardened-сборки

это как?

А gpl? Мутная тема...

Однако ядро Linux по GPL v 2 а твоё мнение несуществеено.

о, OpenBSD вышли в финал

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

о, OpenBSD вышли в финал

один о системд, деревянный про бсд. клоуны.

Туда ему и дорога, если разрабов grsecurity проприерасты покусали, и они нарушать GPL стали. Кому нужно, те патчи от Copperhead OS зающать могут, некоторые арчеводы именно так и делают. А большинству это всё равно не нужно. Мне одно интересно, когда юристы Linux Foundation и FSF прижмут разрабов grsecurity в суде за нарушение лицензии?

за нарушение лицензии

Какого именно пункта?
GPL действует, исходники распространяются, просто grsec прекращают отношения с нарушившими их соглашение. Да, подло, но ничего не нарушает.

Так на фига ебилд, если исходников нету? А кто их будет сливать, когда и бабло под угрозой, и контракт? А прикручивать без распространения у себя я могу как угодно, да, но мне тогда нах не уперлось лицензию писать для этого дела, хватит внутренних документов компании (нда и т.п.)

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

GPL запрешает накладывать на юзеров дополнительные ограничения, а их проприетарное дополнительное соглашение, запрешающее сливать патчи на сторону - что это, как не дополнительные ограничения? Как минимум, нарушающее пункт 3 лицензионного соглашения и пункт 7 этого же соглашения. Я конечно не юрист, и это всецело моё ИМХО, но думаю в любом суде квалифицированные юристы также довольно быстро найдут противорения в условиях, налагаемых доп. соглашением и условиями лицензии GPLv2, запрещающей накладывать такие дополнительные ограничения на юзеров, получивших залицензированный под GPLv2 продукт.

А вот хрен знает как упороши эти воспримут, вон у них как печёт.

Не удивлюсь если они каждому клиенту по идентификатору в исходники надёжно спрячут, чтоб определять слившего. Я ж говорю: попкорном надо запасаться.

Ну они как-бы не запрещают эту копию распространять, просто говорят, что новую версию не дадут. А вот тут совсем другое право, контракт на поставку ПО, который типа можно и разорвать. НО! Лицензию на предыдущие уже полученные копии, естественно, они не отзывают. Казус.

дополнительные ограничения

Код остаётся под GPL, и кто его получил, легитимно им пользуется и распространяет, просто оригинальные авторы больше с такими работать не захотят дальше. И пп 3 и 7 этому не противоречат, GPL-то выполняется.

Есть же ebuilds пакетов, для скачивания или использования которых пользователь сам должен зайти к ним на сайт, иногда принять соглашение (или даже залогинится) или позже подсунуть файл лицензии.

Oracle JRE/JDK нужно скачивать вручную (раньще ещё и тыкать галочку о согласии с лицензией).

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

qtiplot новых версий исходники автор до сих пор не выложил, как раньше. Новостей о смене лицензии я не видел, но и слитых исходников новых версий тоже на просторах не видать.

Лучше несвободная Windows со свободным железом

Это где ты такое видел?

Разупорись же ну! Не нужно ничего писать или сочинять. Вон Pinkbyte не даст соврать - в eapi=6 по дефолту включена фича /etc/portage/patches. Подкладывать свои grsec заплатки да хоть по адресу /etc/portage/patches/sys-kerne/vanilla-sources и получай удовольствие.

Однако, если так посмотреть на эту ситуацию, то это не просто казус. Это - упущение со стороны разработчиков GPLv2(и v3, похоже, тоже). С одной стороны авторы GPL против дополнительных ограничений, не предустмотренных лицензией, с другой стороны - они не предусмотрели возможность подобных казусов, что сделало возможным формально не нарушая GPL, всё-таки налагать на пользователей дополнительное ограничение. Не хорошо как-то получилось.

Спасибо mandala, он уже разъяснил тонкости их договора. Да, получается, что формально GPL они не нарушают, хотя сама лицензия создавалась с расчётом на предотвращения ситауций, когда на пользователей налагаются дополнительные ограничения.

Разупорись же ну! Не нужно ничего писать или сочинять.

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

Предлагаете запретить в следующей версии GPL разрывать договор с пользователем? А чё, нарушается свобода пользователя всегда пользоваться услугами разработчика. Или там нарушается свобода кода всегда быть поддерживаемым.

Да, получается, что формально GPL они не нарушают

Не получается. Нарушают.