On Tue, Sep 15, 2026 at 08:32:48PM +0800, Alexei Takaseev wrote:
> В Вт, 15/09/2026 в 14:58 +0300, Gleb Fotengauer-Malinovskiy пишет:
> > On Tue, Sep 15, 2026 at 02:39:11PM +0400, Ivan A. Melnikov wrote:
> > > On Mon, Sep 14, 2026 at 02:53:10PM +0300, Gleb Fotengauer-
> > > Malinovskiy wrote:
> > > > On Mon, Sep 14, 2026 at 02:44:27PM +0400, Ivan A. Melnikov wrote:
> > > > > On Mon, Sep 14, 2026 at 06:18:27PM +0800, Alexei Takaseev
> > > > > wrote:
> > > > > > Добрый день!
> > > > > > 
> > > > > > При сборке модуля для ядра kernel-image-rockchip64 получается
> > > > > > вот такое
> > > > > > сообщение:
> > > > > > 
> > > > > > ====
> > > > > > 2026-Sep-14 10:01:58 :: [aarch64] #200 kernel-modules-yt6801-
> > > > > > rockchip64.git sisyphus/kernel-modules-yt6801-rockchip64-
> > > > > > 1.0.31-alt2:
> > > > > > build start
> > > > > > 2026-Sep-14 10:02:50 :: [aarch64] #200: modsigning approved
> > > > > > by cas
> > > > > > 2026-Sep-14 10:03:14 :: [aarch64] remote modsign: failed to
> > > > > > modsign
> > > > > > kernel-modules-yt6801-rockchip64-1.0.31-
> > > > > > alt2.397875.1.aarch64.rpm
> > > > > > ====
> > > > > > 
> > > > > > Действительно, для этого ядра не предусматривается процедура
> > > > > > подписания
> > > > > > модулей внешним ключем. Есть ли у сборочницы крутилки,
> > > > > > выключающие
> > > > > > процедуру подписания там, где она не нужна?
> > > > > 
> > > > > Привет Глеб.
> > > > > 
> > > > > Можешь подсказать, что тут cделать?
> > > > > 
> > > > > Как будто бы сейчас сборка будет работать только если её
> > > > > поаппрувит
> > > > > кто-то из @maint, но не из @modsign.
> > > > 
> > > > По сути, мне кажется, что не предполагалось, что кто-то хочет не
> > > > подписывать модули для ядер.
> > > 
> > > Для массового сервиса, рекомендованного всем и каждому собирателю
> > > ядер, modsign'илке как минимум очень сильно не хватает
> > > документации.
> > 
> > Я согласен, не хватает.  К сожалению, реализация и внедрение подписей
> > произошло практически без ценного вклада этих самых собирателей ядер.
> > К счастью, всё ещё можно сформулировать запрос с вашей стороны,
> > поменять реализацию на подходящую и задокументировать её.
> 
> Собственно, это запрос и есть - иметь возможность вернуть поведение
> сборочницы в первоначальное состояние.

Какой должен быть интерфейс?

В какой степени и как именно сборочница должна не давать вам и другим
мейнтейнерам ядер забыть подписать модули, если modsign всё же
используется?  Почему (кроме отсутствия документации) мейнтейнер ядра
может хотеть отказаться от modsign совсем?  Через какой интерфейс?

> > > > Хотелось бы понять, какое решение тут будет лучше, потому что
> > > > самое
> > > > простое решение: сделать список ядер, модули которых не надо
> > > > подписывать.
> > > 
> > > Мне кажется, что отсутстве ключа для ядра не должно быть ошибкой
> > > в общем случае. Форсить modign нужно только для ядер из
> > > $GB_PESIGN_PACKAGES.
> > 
> > C этим я не очень согласен.  Я не вижу никаких причин не подписывать
> > модули для ядер и это никак не связано с тем, есть ли в ядре enforce
> > подписей и подписывается ли оно с помощью pesign.  Связь есть только
> > в
> > обратную сторону, т.е. если в ядре есть enforce, то модули нельзя не
> > подписывать и если есть pesign, то должен быть enforce.
> > 
> > Но если кому-то очень надо *не подписывать* ядерные модули для
> > конкретного
> > ядра, можно реализовать в сборочнице именно это, хоть мне и кажется,
> > что
> > это странная идея.  Отсутствие же ключа может значить, не только, что
> > майнтейнер ядра не хочет подписывать модули, но и то, что он просто
> > забыл/ошибся при выписывании нового ключа для ядра.
> 
> Идея не странная. Механизм был добавлен и активирован по-сути явочно.
> Со времени первого анонса от 3 июня никакого описания и документации
> так и не появилось.

Что поделать, вводить kernel lockdown нужно было срочно, реализация всё
ещё не устраивает (что значит, что документацию писать может быть рано),
а желающих писать документацию тоже не нашлось.

> Про шаманство с аппрувом от нужной группы для подписи oot модуля
> становится известно из личных переписок.

Такой подход не нов и используется в сборочнице для подписи ядер примерно
с 2013 года.

> "Собиратели ядер" может и не против применения новых возможностей, но
> они должны быть описаны и документированы.

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

-- 
glebfm